|
Home > |
|
|---|
В общем случае есть два способа доступа к Модулю:
>Административный заход через SSH или через локальное терминальное соединение с интерфейсом командной строки LunaSH
>Клиентский заход по SSL, через который клиентское приложение, использующее SafeNet Luna Network HSM API , выполняет криптографические функции в определенном виртуальном HSM (его называют “партиция”) созданном внутри физического HSM
В варианте SafeNet Luna HSM с парольной аутентификацией, аутентификация пользователей HSM, их ролевые полномочия защищены паролями.
Для выполнения задач администрирования (таких, как установление действующих на весь HSM политик, обновление прошивки и конфигурирование функций, создание резервных копий, восстановление с резервных копий, создание или удаление партиций и пр.), Вам нужно будет зайти в LunaSH ролью admin и затем - в качестве HSM Admin c паролем HSM Admin (для каждого HSM предусмотрена только одна такая роль). Хорошей практикой безопасности будет, если пароли для appliance admin и HSM Admin будут различными.
Для выполнения задач по администрированию партиций (установление политик для партиций, выделение партиций клиентам, удаление клиентов, и пр.), Вам нужно сначала зайти в LunaSH в роли admin, затем зайти в качестве Partition Owner (таких может быть несколько - по одному на каждую партицию) с паролем, назначенным для роли Partition Owner. Хорошей практикой будет, если все пароли различаются. Partition Owner может сразу зайти в систему локально через терминальное соединение, или удаленно – тогда сначала придется ввести пароль для admin чтобы получить доступ к Модулю, командному интерфейсу LunaSH а затем пароль для Partition Owner чтобы иметь доступ к управлению партициями.
Для того, чтобы клиентское приложение (клиент) смогло получить доступ к партиции и выполнить криптографические операции, Partition Owner должен его предварительно авторизовать и зарегистрировать. Затем приложение по протоколу SSL (в нашей реализации мы называем его NTLS) соединяется с Модулем. После установления соединения клиент передает информацию о роли, в которой он хочет зарегистрироваться (User-type ) и предъявляет пароль (Partition Password ).Это тот же самый пароль, который использует Partition Owner. На первый взгляд это выглядит небезопасно, однако полномочия клиента ограничены тем, что для администрирований партиций нужно иметь доступ к LunaSH, а для этого нужен пароль к LunaSH. Таким образом, по соображениям безопасности, клиент не должен “знать” пароль appliance admin, который и даёт доступ к LunaSH.
Объекты в HSM зашифровываются владельцем Admin (the owner of the HSM Admin space) или User space (partition), и могут расшифровываться и только после ввода пароля администратором HSM (пользователем HSM Admin) или пользователем партиции (partition User) соответственно.
NOTE Пароль администратора используется также и для аутентификации приложений, подключающихся к HSM т.е. это один и тот же секрет, который используется для двух разных целей. И, таким образом, для HSM с парольным вариантом аутентификации, после того, как администратор (Crypto Officer или Crypto User) дали пароль приложен\ию/ям, единственным способом ограничить доступ тем, кому был выдан пароль, это его поменять.
>Удобство: поменять пароли легко, и это можно быстро сделать в случае смены персонала или подозрения утечки данных
>Отлично встраивается в схему политики безопасности организации – правила регулярной смены паролей обычно уже присутствуют.
Использовать пароли менее безопасно, нежели чем двухфакторную аутентификацию и это приводит к существенным проблемам:
>пароль легко подсмотреть: это может сделать человек, камера или key-logger.
>пароль надо где-то хранить – по-настоящему безопасные пароли сложны для запоминания и их приходится записывать и хранить в безопасном месте.
>ответственность в случае утечки: сложно доказать кто подсмотрел пароль или кому его сказали.