Не всегда безопасность можно обеспечить навесными контролями, да и плохо работают навесные контроли, встроенная безопасность - значительно лучше, поэтому многое в безопасности зависит от процессов. Один и тот же процесс можно делать безопасно и небезопасно. При этом, если мы хотим, чтобы пользователи использовали именно безопасный вариант процесса, он должен быть удобным для использования. Если использование безопасного варианта процесса будет связано с множеством неудобств для пользователя, он не будет стремиться использовать безопасный процесс (а, может, и напротив, стремиться обойти наши безопасные процессы!), и при любой возможности будет сваливаться в использование небезопасного процесса, а это уже наша с вами проблема, проблема Безопасности.
Использование PKI в корпоративной сети - абсолютно необходимы контроль. Можно строить системы с защитой конфиденциальности данных, подтверждением авторства, контроля целостности, с использованием стойкой криптографии.
Одной из моих прошлых ролей, которой я посвятил несколько лет, была - администратор корпоративной PKI и архитектор решений с использованием криптографии. Я работал с RSA Keon и Microsoft CA. В воспоминаниях того времени, остались шпаргалка по certutil и замечательная книжка Брайана Комара (поделюсь ей в канале). Поскольку, в своей работе я всегда стремился сделать решения, которые будут удобны, количество пользователей, использующих различные криптографические схемы, постоянно росло, а этот рост требовал от нас еще большей ответственности в отношении удобства использования предложенных нами безопасных схем с использованием криптографии.
Очевидным элементом удобства является возможность всегда прочитать свою шифрованную S/MIME почту, при условии, что приватный ключ хранится на токене и никогда не покидает его (всякие нелепые схемы хранения ключевого материала мы, конечно же, не рассматриваем). Однако, риск потери токена пользователем - высокий, поэтому его следует рассматривать при проектировании корпоративной PKI. Кроме того, получение доступа к корпоративной переписке может потребоваться и для случаев внутренних расследований, поэтому, давая возможность пользователям использовать стойкую криптографию для сокрытия своей переписки, мы у себя под носом, собственноручно, создаем неконтролируемый канал утечки, что ставит под сомнение вообще всю идею обеспечения конфиденциальности. Также подобный доступ может потребоваться и в рамках соответствия требованиям отраслевых и государственных регуляторов. Нужно также понимать очень простую вещь: зашифровать данные и потерять ключ - равносильно надежному удалению этой информации - мы хотим, чтобы пользователи имели возможность так просто делать корпоративные данные недоступными?
Решение здесь очевидное - депонирование ключей, т.е. все закрытые ключи пользователя сохраняются в AD и могут быть восстановлены при необходимости. На первый взгляд это звучит дико и небезопасно, однако, если позаботиться о правильной организации процесса восстановления и хранения ключа Агента восстановления, особых проблем для безопасности здесь не создается, тогда как выгоды невозможно переоценить: и пользователи и уполномоченные службы всегда могут получить доступ к зашифрованным данным.
Депонированные ключи хранятся в AD, зашифрованные на отрытом ключе Агента восстановления. Т.е. вся безопасность схемы депонирования зависит от безопасности хранения закрытого ключа агента восстановления, и самой процедуры восстановления. И здесь можно предложить следующие простые мероприятия (по вашему решению мероприятия могут отличаться, я просто описываю как это было в моем случае).
- Закрытый ключ агента восстановления хранится на токене. Токен защищен PIN-ом и физически хранится в сейфе. Пин известен группе восстановления, они же имеют доступ в сейф. Группа восстановления - подразделение ИБ.
- Восстановление ключей производится на выделенном АРМ. АРМ, насколько это можно, захарденено: защищается с использованием хорошего EPP, можно, чтобы он имел адрес в выделенной подсети (чтобы снизить риск его атаки по сети), на АРМ своевременно ставятся обновления. В нашем случае это была виртуалка, которая всегда была выключена и поднималась только когда требуется проведение операции восстановления.
- С АРМ собираются логи, т.е. воспользоваться этой машиной незаметно невозможно. Тем более невозможно незаметно выполнить работу Агента восстановления.
- Агенту восстановления разрешен вход только на этот АРМ. По возможности, нужно снизить риск использования Агента восстановления на любом другом компьютере в сети.
- Есть бумажный процесс восстановления: подается заявка, ее согласует руководитель заявителя и, если причина необходимости восстановления выглядит объективно (можно написать Регламент, где перечислить допустимые причины восстановления) для подразделения ИБ, выполняется восстановление ключей.
- Восстановленные ключи сразу записываютя на токен без возможности экспорта закрытого ключа.
- Артефакты восстановления ключей, сохраняемые на АРМ Агента восстановления в процессе, типа, промежуточных блобов и контейнеров PKCS12 - надежно удаляются с перезаписью.