За семью замками - настраиваем максимальную безопасность для использования МКДО в организации
| Содержание: |
Введение
Когда дело доходит до электронных подписей, начинают возникать вопросы касательно безопасности. А когда появляются требования установки закрытого ключа электронной подписи на сервер - начинает беспокоиться служба безопасности организации, что сильно влияет на дальнейшее развитие продукта с такими требованиями в организации.
Цель этой статьи рассказать, как максимально обезопасить закрытый ключ от компрометации, что делать, если он был скомпрометирован, и как избежать весомых последствий.
Технические требования и рекомендации
Первым делом необходимо понять, что от нас требуется для организации МКДО и какие есть рекомендации. Все требования и рекомендации перечислим ниже:
- Сервер для DISI с доступом в Интернет;
- Локальная усиленная квалифицированная электронная подпись (обычно от КриптоПро/CryptoPro), соответствующая федеральному закону РФ №63 "Об электронной подписи";
- Зарегистрированная организация на сервисе обмена документами (Диадок, Synerdocs или др.), с которыми сейчас есть коннекторы у системы DIRECTUM. Причём у этой организации для отправки документов контрагентам уже должен быть оплачен тариф на обмен, а также желательно уже настроена структура подразделений и заведены все необходимые сотрудники. Если предполагается только приём документов (без отправки), приобретать что-то на сервисе нет необходимости, хватит только регистрации и настройки.
- Система DIRECTUM. В зависимости от требований к возможностям обмена есть рекомендации по версиям системы:
- До 5.4 - обмен только неформализованными документами. На данный момент работа МКДО на версиях ниже 5.4 нестабильна, поэтому рекомендуется обновить систему до более новых версий.
- 5.4 - реализован только приём формализованных документов, отправка невозможна (обмен неформализованными документами возможен).
- 5.4.1 - обмен формализованными и неформализованными документами.
- 5.4.3 - обмен с контрагентами в роуминге (в версиях ниже не поддерживается, могут возникнуть конфликты);
- 5.5 - удобная работа с формализованными документами в модуле "Финансовый архив" (в виде модуля, а не технического решения);
- 5.5.1 - красивые и информативные штампы на печатных формах документов;
- 5.6 - удобная настройка модуля "Финансовый архив", удобное массовое подписывание и выдача полномочий, повышенная стабильность работы.
- Если планируется использование любой другой системы обмена кроме Synerdocs - купленная лицензия коннектора к этой СОД (из списка поддерживаемых) и установленный дистрибутив данного коннектора.
- Закрытый ключ электронной подписи должен быть установлен на сервере с установленной службой DISI для автоматического подписания служебных документов.
Обычно вопросы возникают как раз в последнем шестом пункте. Но об этом ниже.
Варианты компрометации закрытого ключа
Итак, мы установили службу DISI и начинаем обмениваться с контрагентами финансовыми документами. Сама по себе электронная подпись обеспечивает очень хорошую защиту от незаконных действий, так что влезть без следов в уже установленную подпись практически невозможно. А тем более сделать так, чтобы проверка на сервисе обмена не выявила подмены - и вовсе задача невыполнимая. Чего же нам бояться в таком случае?
Вспомним общую схему взаимодействия: Человек -> ЭЦП -> Сервер -> Сервис. Начнём рассматривать точки внедрения нашего воображаемого шпиона в каждое звено этой цепи.
- Атака на сам сервис практически бесполезна, так как там существует много ступеней защиты. Не зря сервис обмена документами обеспечивает юридическую значимость передаваемых через себя документов. Вариант отпадает.
- На стыке отправки электронного документа в сервис наш шпион тоже не сможет вмешаться, всё же защищённые протоколы https порой творят чудеса.
- В саму ЭЦП, как мы выяснили выше, вмешаться тоже невозможно бесследно.
- Сразу скажу, что воздействие на человека мы не рассматриваем, ведь мы полностью доверяем ответственному за ЭЦП, на которого она была выписана.
- Остаётся только атака на сервер для получения образца закрытой подписи. Это самый простой и, пожалуй, логичный вариант компрометации закрытого ключа.
Таким образом мы вычислили, где наш, напомню, воображаемый шпион может расставить свои сети и нанести удар по конфиденциальности закрытого ключа. Теперь же приступим к строительству нашей супер-защищённой цифровой крепости.
Цифровая крепость
В данном разделе мы начнём с самых первичных мер противодействия компрометации закрытого ключа с сервера и закончим наиболее защищёнными вариантами, требующими значительного усложнения работы. Какой уровень защиты устанавливать для себя - выбирать только вам. Но помните, что чем сильнее ваша защита, тем она менее удобна в использовании.
Уровень первый.
Кратко: настраиваем список пользователей имеющих право удалённого подключения к серверу.
Подробно:
Первый способ защитить сервер от попыток туда проникнуть и что-то украсть - это в принципе не давать возможности для подключения сторонних пользователей. Или же выдать доступ только для определённых пользователей (например, владельца закрытого ключа). Сделать это можно, поменяв параметры удалённого доступа к серверу в настройках системы Windows.
Например, можно настроить как на скриншоте:
После этого доступ будет предоставлен только пользователям, которые здесь указаны. Либо же в этой же настройке полностью запретить удалённое подключение к серверу.
Уровень второй.
Кратко: выделяем локального админа и доменного пользователя для выделенного сервера DISI.
Подробно:
Доверие в организации всегда находится на уровне того, насколько мы доверяем своим администраторам. Администраторы выступают глобальными регуляторами процессов в организации, которые имеют доступ к практически любой информации (а при нужных действиях - ко всей информации, если это специально не ограничить).
Но обычно в организациях есть некий домен, где можно очень подробно настроить возможные права для пользователей. А ещё машина "в домене" имеет свойство давать любому пользователю заходить на неё под своим уникальным в сети пользователем, даже если его отдельно в системе не завести. Используя эти две возможности, мы можем выстроить ещё одну "линию обороны".
Идея проста - на каждой машине могут быть как локальные администраторы, которые могут об этой машине заботиться, так и доменные, которые имеют права вообще ко всему, в том числе, к примеру, доступ к смене паролей доменных пользователей. И если доменный администратор в этом смысле "божество", то локальный администратор - это некий "локальный бог конкретной машины". И менять пароли он может только у локальных пользователей. На этом и строится этот способ защиты.
Для администрирования службы DISI на этом сервере мы создаём локального администратора. Он будет обслуживать службу, перезапускать её, анализировать логи и так далее. Сама служба будет работать от доменного пользователя, который зайдёт на этот компьютер и внесёт свой закрытый ключ в Личное хранилище реестра сертификатов.
Что это нам даёт?
- У нас всегда есть локальный администратор, который администрирует и следит за службой DISI, но фактически может отличаться от доменного администратора;
- У локального администратора нет привилегий менять пароль пользователя домена, а значит физически нет возможности получить доступ к его профилю.
Юридическая сторона вопроса
Если посмотреть на всю ситуацию с юридической стороны, то мы придём к выводу, что компрометация закрытого ключа - это тоже самое, что потеря банковской карты. То есть это нечто, что может представлять вас и ваши интересы, что-то, чем вы можете подтвердить своё согласие с поставленными условиями.
Защититься от последствий компрометации можно с этой стороны. Первым делом рассмотрим, что нужно сделать перед началом работы с ЭП, чтобы снизить риск наступления нежелательной ситуации:
- Оформить приказ о назначении ответственного за подпись первичных документов и служебных документов. В связи с этим удобно использовать следующую схему:
- На сервисе обмена регистрируются 2 профиля - Директора и Секретаря;
- Подписью Директора могут быть подписаны все финансовые документы и договора;
- Подписью Секретаря могут быть подписаны только служебные документы;
- Служба DISI работает из под профиля Секретаря, на сервис отправляется финальная подпись на документах от Директора.
- Этот приказ должен быть заверен юридическим отделом.
Эти действия могут помочь в дальнейших разбирательствах, если будут незаконно подписаны какие-либо договора, соглашения или финансовые документы.
Также обязательно знать, что нужно делать, когда стало известно об компрометации закрытого ключа:
- Сообщить удостоверяющему центру, который выпустил закрытый ключ, о его компрометации с просьбой его отзыва и перевыпуска;
- Заменить скомпрометированный ключ на новый во всех местах, где он ранее использовался (у пользователя, на сервере DISI, на сервисе обмена);
- Проверить документы, подписанные данным закрытым ключом с момента предполагаемой компрометации. Если такие документы есть - запустить процесс их аннулирования текущих документов и запрос новых для правильного согласования и подписания.
Если после всех этих действий появятся вопросы от контрагентов или ФНС, вам необходимо будет предоставить:
- Информацию об отправленном запросе на перевыпуск закрытого ключа;
- Сведения о факте подписания этим закрытым ключом ключевого документа, по которому возникли вопросы (например, скриншот о установленных подписях на документе в программе OverDoc);
- Приказ, в котором подписанный вид документа не входит в перечень тех, которые разрешено подписывать этим закрытым ключом.
Таким образом при утечке информации у вас будет возможность быстро вернуть контроль над ситуацией.
Краткие выводы
Если подводить итоги статьи, то будет правильным первым делом сказать следующее: размещение закрытого ключа на сервере - это далеко не всегда небезопасно. А вот основная уязвимость любой информационной системы в первую очередь - это пользователь. Тем более пользователь с широким кругом прав и возможностей.
Поэтому к данному вопросу нужно подходить не только с технической стороны, но и юридической. Рассматривать обеспечение безопасности нужно с учётом обоих сторон, достигая баланса между уровнем безопасности и удобством.
В комментариях же вы можете поделиться своим опытом и мнением на этот счёт. А ещё разными уловками и программами для защиты закрытых ключей, которыми вы сами пользуетесь и готовы порекомендовать другим.
Использование локальных (недоменных) учетных записей - не очень хорошая практика, особенно - локальных учетных записей с администраторскими полномочиями. В некоторых компаниях это просто запрещено. Сама по себе локальная учетная запись не хуже и не лучше доменной, но ею невозможно централизованно управлять. Это такое мелкое "исключение из правил", о котором легко забыть, местная особенность, костыль, ухудшающий контроль над ИТ-инфраструктурой организации.
Вообще, размещение закрытого ключа на сервере довольно сложно согласовывать со службами безопасности.
Максим, спасибо за статью!
А есть ли способ избежать ситуации, когда приходится думать о корректном юридическом обеспечении, безопасности доступа, недопущения компрометации сертификата и пр.?
Хочется понять основные ограничения и неудобства, которые не позволяют работать «очному пользователю» по схеме «получил задание-вставил токен-подписал-сработала служба подписания и отправки-подписались служебные документы-достал токен».
Цитата: "Сразу скажу, что воздействие на человека мы не рассматриваем, ведь мы полностью доверяем ответственному за ЭЦП, на которого она была выписана."
Как и следует из вывода - очень грубое допущение. Львиная доля "проколов" безопасности - человеческий фактор, при том - непреднамеренный, и сбрасывать её со счетов не стоит.
Так же согласен с Бапиным Р., в части наличия на серверах локальных УЗ с повышенными полномочиями, этим так же не следует пренебрегать, в первую очередь из-за того, что велико влияние человеческого фактора.
Помимо ограничений на удаленное подключение для УЗ, было бы не лишним учитывать топологию информационной сети предприятия так, чтобы к критическим сегментам сети, где находятся серверы, доступ был только с определённых участков сети или определённых рабочих станций, к которым предъявлены повышенные требования безопасности в частности парольных политик и политик антивирусной защиты (https не позволит сниффить трафик, но ведь есть и кей-логгеры).
А еще небольшое дополнение к действиям при компрометации ключа - прежде чем его менять, нужно выявить место утечки, иначе выйдет так, что вновь выпущенный ключ сразу же окажется скомпрометирован - да, это затормозит бизнес-процессы предприятия, но принятые меры не будут напрасны.
Но в целом, мне так же как и Андрею не понятно - зачем выносить формирование ЭП по именному закрытому ключу на удаленный сервер? Ведь безопаснее формировать ЭП на рабочем месте пользователя с запросом PIN-кода от ключевого носителя, который должен знать только владелец. В случае, если установка ЭП требуется по доверенности - то можно выписать доверенность на саму ключевую пару.
А касательно ФЗ-63 имеется противоречние со ст. 10 п.1: "1) обеспечивать конфиденциальность ключей электронных подписей, в частности не допускать использование принадлежащих им ключей электронных подписей без их согласия;", т.е. как только ты отдал свой ключ в реестр удаленного сервера - ты больше не отвечаешь за его конфиденциальность, если не ЛПА не предусмотреть иное.
Руслан Бапин, извиняюсь, что-то я задержался с ответом.
В данной статье я рассматривал именно исключение из правил. А причина проста - локальный администратор не сможет сменить пароль у доменного пользователя. И у него в принципе нет доступа к доменным политикам. Да, это обоюдоострый меч - с одной стороны мы защищаем таким образом пользователя от смены пароля, но с другой теряем возможность доступа к учётке и управление ей через AD. В любом случае, использовать такую тактику или нет - выбор администраторов и безопасников организации. Я лишь рассмотрел этот вариант как допустимый.
>> Вообще, размещение закрытого ключа на сервере довольно сложно согласовывать со службами безопасности
Это да, поэтому я и постарался описать в статье, как подойти к разговору со службой безопасности не просто с причиной "а вот хочу закрытый ключ на сервере и всё!", а обоснованно, с вариантами настройки уровня безопасности. Но если и это не поможет - что ж, тут уже ни чем не помочь. Во всём, даже в очень хорошем (намёк на безопасность), надо знать меру.
P.S. Но опять же всё зависит от уровня и спецификации предприятия. Если на нём делаются гос. заказы с высокой секретностью - такая безопасность оправдана.
Андрей Николаев,
>> А есть ли способ избежать ситуации, когда приходится думать о корректном юридическом обеспечении, безопасности доступа, недопущения компрометации сертификата и пр.?
Если на чистоту, то об этом лучше думать всегда. Вы же не оставляете банковскую карту на кассе в магазине, пока ходите за покупками со словами "пусть тут полежит, вернусь - ей оплачу"?))
Тут примерно тоже самое. Сама специфика ЭП говорит, что нам всегда нужно думать про её безопасность и всегда иметь "пути отхода".
>> Хочется понять основные ограничения и неудобства, которые не позволяют работать «очному пользователю» по схеме «получил задание-вставил токен-подписал-сработала служба подписания и отправки-подписались служебные документы-достал токен».
Такая схема работает в текущих версиях системы. Хотя и не рекомендуется.
Причины:
Собственно, это основные причины. Если ещё остались вопросы - задавайте.
Михаил Александров,
>> Как и следует из вывода - очень грубое допущение. Львиная доля "проколов" безопасности - человеческий фактор, при том - непреднамеренный, и сбрасывать её со счетов не стоит.
Так же согласен с Бапиным Р., в части наличия на серверах локальных УЗ с повышенными полномочиями, этим так же не следует пренебрегать, в первую очередь из-за того, что велико влияние человеческого фактора.
Абсолютно согласен, что человеческий фактор чаще всего и является основной причиной проколов безопасности. Но что мы, как вендор продукта, сможем сделать с нерадивым администратором какого-нибудь клиента? У меня возникает только мысль разработать и выпустить чип и вживлять его в мозги администраторов, чтобы он не давал возможности накосячить или слить данные "по дружбе" своему приятелю. Но это уже совсем другая история...
>> Помимо ограничений на удаленное подключение для УЗ, было бы не лишним учитывать топологию информационной сети предприятия так, чтобы к критическим сегментам сети, где находятся серверы, доступ был только с определённых участков сети или определённых рабочих станций, к которым предъявлены повышенные требования безопасности в частности парольных политик и политик антивирусной защиты (https не позволит сниффить трафик, но ведь есть и кей-логгеры).
Тоже об этом думал. Но по сути это уже не наша работа, а работа администраторов и безопасников. Как я писал, всё упирается в баланс безопасности и удобства.
Допустим, нужный админ заболел. Если у нас продумана максимальная защита, то, чтобы его заменить другим работником (пусть даже временно), нам нужно будет "прогнать" этого человека по куче отделов предприятия для согласования, выдать все нужные права, проверить его личность (сетчатка глаза, отпечатки пальцев, ДНК крови), проверить его на судимости (а вдруг?), провести анализ его окружения и родственников, которые могли быть причастны к нарушениям закона (самого сотрудника, конечно же, тоже проверить), взять подписки о соблюдении конфиденциальности и ещё тысячи разных проверок. Удобно ли это, чтобы просто заменить админа на пару дней? Не думаю. Но в любом другом варианте безопасники нас порвут как Тузик грелку, если мы нарушим хоть один из пунктов. И не важно, работал этот заменяющий 10 20 или 30 лет уже в компании.
>> А еще небольшое дополнение к действиям при компрометации ключа - прежде чем его менять, нужно выявить место утечки, иначе выйдет так, что вновь выпущенный ключ сразу же окажется скомпрометирован - да, это затормозит бизнес-процессы предприятия, но принятые меры не будут напрасны.
Кстати, да, это очень важное и полезное замечание. Спасибо!
>> как только ты отдал свой ключ в реестр удаленного сервера - ты больше не отвечаешь за его конфиденциальность
Но отдал же ты не просто так? У тебя его не забрали, не выведали пароль к нему под пытками. Ты самостоятельно (в описанном в статье варианте) установил его в реестр, в личное хранилище. А значит аргумент "без их согласия" тут не может рассматриваться, ты был согласен на использование ключа по данному назначению. Также стоит заметить, что этот закрытый ключ подписывает только служебные документы, обычные документы (счета-фактуры, акты и т.д.) подписывают сами пользователи на своих рабочих местах своими закрытыми ключами. И там уже можно установить пин-коды, использовать токен и так далее, что душе угодно.
Авторизуйтесь, чтобы написать комментарий