Начнем с примера. Некоторое время назад к нам обратились представители реальной сервисной компании, которые спросили: «Что нам нужно сделать, чтобы наш сервис можно было использовать для ГИС? А также и для ИСПДн, для АСУ ТП, и объектов КИИ... Нам же нужна только сертифицированная среда?». Мы стали уточнять: «Как только сертифицированная среда? А сам продукт, а ваш сервис? И кому, собственно, этот сервис предлагается?». Тогда коллеги, уже с некоторым сомнением, ответили: «А нам сказали, что сам продукт не нужно сертифицировать!». 

Итак, даже сотрудники компании с опытом предоставления реальных сервисов в области информационной безопасности недостаточно разобрались в том, как строятся и предоставляются сервисы для государственных информационных систем (ГИС), объектов критической информационной инфраструктуры (КИИ) и других информационных систем. Они посчитали, что если сервисная компания развернула некую сертифицированную среду виртуализации, аттестовала ее, то автоматически стала свободной! И теперь может развёртывать какие угодно решения и оказывать на их основе кому угодно и какие угодно сервисы! К слову сказать, другие наши потенциальные партнеры, наоборот сочли, что сервис на базе сертифицированного 2FA-решения вообще не может быть «облачным». Так где же истина? Попробуем разобраться. 

Государственные информационные системы. По приказу ФСТЭК России от 11 февраля 2013 г. №17, владельцы ГИС обязаны осуществлять аттестацию своих систем и использовать только сертифицированные средства защиты информации. Многофакторная аутентификация – это один из механизмов обеспечения информационной безопасности, поэтому используемое решение 2FA должно быть сертифицировано. В то же время, многие производители сертифицированных средств защиты информации (даже сертифицированных по высокому уровню доверия и по высокому классу) официально уведомляют, что используют внешние механизмы многофакторной аутентификации. И, не смотря на то, что решения этих производителей сертифицированы, заказчики при аттестации своих информационных систем неизбежно столкнутся с тем, что важная часть механизмов обеспечения ИБ этими сертифицированными средствами не реализуется. Получается, что нужно будет где-то отдельно взять сертифицированные 2FA-решения! Как вы понимаете, есть два варианта:

1. Закупить и развернуть в своей информационной инфраструктуре сертифицированное средство 2FA. Как это сделать правильно мы в нашем цикле статей не рассматриваем, сам производитель наверняка поможет и подробно проконсультирует.
2. Воспользоваться сервисом, развернутым на базе сертифицированного средства 2FA. Вот только получить этот сервис необходимо, условно говоря, «как аттестованный».

Итак, когда организация, эксплуатирующая или подключающаяся к ГИС, выбрала использование 2FA-сервиса (а как принимать решение в пользу сервиса и на что при этом обращать внимание мы рассмотрели во второй и в третьей статье), необходимо получить у поставщика именно «аттестованный» сервис. Это означает, что сам сервис должен быть реализован на базе сертифицированного решения 2FA, а информационная система (информационная инфраструктура) поставщика, в которой данный сервис развернут, должна быть аттестована. 

По нашему опыту, аттестованный сервис 2FA подходит организациям, эксплуатирующим или подключающимся к ГИС, в следующих случаях:

• малое количество пользователей сервиса двухфакторной аутентификации (например, несколько администраторов и несколько ключевых пользователей);
• отсутствие возможности и\или необходимых ресурсов для внедрения сертифицированного средства 2FA и организации собственного внутреннего сервиса;
• другие ограничения, возникшие из-за специфики организации, эксплуатирующей или подключающейся к ГИС.

Прочие информационные системы — ИСПДн, АСУ ТП, КИИ. По требованиям законодательства (в частности, № 152-ФЗ «О персональных данных, № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации», № 149-ФЗ «Об информации, информационных технологиях и о защите информации», а также Приказа ФСТЭК России от 21 декабря 2017г. № 235 и Приказа ФСТЭК России от 25 декабря 2017г. № 239) решение об использовании сертифицированных средств обеспечения ИБ в таких системах принимает сам оператор. Если он принял решение, что сертифицированные средства ему необходимы, тогда он может(!) их использовать. А если решил, что сертифицированные средства ИБ он использовать не станет, то никто не может его заставить или потребовать. Соответственно, когда такая организация столкнется с потребностью усиления базовых функций аутентификации в своих информационных системах и примет решение использовать 2FA-сервис, то она сама может определить использовать ли сервис на базе сертифицированного решения или нет. 

Мы считаем, что аттестованный сервис на базе сертифицированного решения 2FA может подойти лишь тем операторам систем ИСПДн, АСУ ТП и КИИ, которые воздерживаются или по какой-то причине не имеют возможности провести самостоятельную оценку соответствия требованиям в виде приемки или испытаний используемых средств защиты информации. В этом случае аттестованный 2FA-сервис может помочь снизить риски, связанные с проверками регулирующих органов. 

Рискнем предположить, что при эксплуатации перечисленных выше информационных систем (ИСПДн, АСУ ТП, КИИ) критерием выбора между сертифицированным или несертифицированным решением 2FA, а также сервисами на их основе, является зрелость службы обеспечения ИБ на конкретном предприятии. 

Те службы ИБ, которые имеют опыт разработки ОРД, моделирования угроз безопасности своих информационных систем, имеют опыт внедрения программных и аппаратных средств защиты информации и самостоятельного проведения их испытаний, и, самое главное, которые содержат в своем штате соответствующих высококвалифицированных сотрудников — такие службы ИБ, скорее всего, предпочтут сертифицированные средства не использовать. Во-первых, это более бюджетный вариант, поскольку, как правило, сертифицированные решения стоят дороже своих несертифицированных аналогов. А во-вторых, использование несертифицированных решений и, соответственно, «облачных» сервисов на их основе может дать ту необходимую гибкость и удобство использования информационных систем, которые от службы ИБ ожидают конечные пользователи и руководство. 

Если же в штате организации, нет достаточного количества высококвалифицированных сотрудников ИБ, обладающих таким опытом (особенно в специфической области многофакторной аутентификации), то вариант использования сертифицированных средств обеспечения ИБ и облачных аттестованных сервисов на их основе, вполне может быть рассмотрен. 

Принимая решение использовать несертифицированные решения для обеспечения ИБ своих информационных систем (справедливо только для ИСПДн, АСУ ТП, КИИ) и возлагая на себя ответственность в виде их самостоятельных испытаний и приемки, организации приобретают возможность выбирать и использовать те средства обеспечения ИБ, которые им больше всего подходят: как сертифицированные, так и несертифицированные. Совершенно точно не нужно бояться использовать несертифицированные средства и сервисы, построенные на их основе. Как мы с вами говорили: для пользователей они могут обеспечить большую гибкость, а для организации позволяют экономить бюджет. А вот есть ли преимущества использования сертифицированных решений и аттестованных сервисов? В чем эти преимущества заключаются? 

Представим себе, что сервис-провайдер предоставляет облачный сервис многофакторной аутентификации, который заказчик использует в критическом процессе – для аутентификации пользователей в своих ключевых системах. Очевидно, что доступность такого сервиса должна быть высокой. Потеря доступности может наступить из-за выхода из строя технических средств, из-за ошибок администраторов, но, в том числе, и из-за НСД. Поэтому механизмы обеспечения ИБ такого сервиса чрезвычайно важны. И при выборе облачного сервиса на базе сертифицированного 2FA-решения заказчик в дополнении к тем этапам выбора и внедрения, которые мы сформулировали в предыдущей статье, просто обязан убедиться, что все вопросы безопасности при организации сервиса решены. И аттестация является одним из доказательств этого! Почему мы это можем утверждать? 

Качество проведения испытаний. Наш опыт показывает, что в настоящее время все результаты испытаний, проводимых при аттестации, подвергаются проверке регулятора. Поэтому все организации, которые проводят испытания, проводят их не формально, а внимательно, педантично и профессионально. Все проверки связаны не только с формальной проверкой регуляторных требований, но и с «полевыми» испытаниями реализации функций безопасности и оформлением соответствующих протоколов. В частности, в процессах аттестации проводятся: проверка наличия модели угроз и ее подробный анализ, проверка согласования модели угроз с регулятором, анализ проектной документации, подтверждающий эффективность борьбы с актуальными угрозами, а также анализ уязвимостей (которые реально обнаруживаются и устраняются) и функциональное тестирование, подтверждающее факт реализации требуемых мер безопасности. 

Проверка наличия ОРД. Безусловно, в рамках аттестационных испытаний мы с вами не можем проверить абсолютно все процессы, но мы проверяем, что процессы задокументированы, что позволяет обнаружить ошибки в их организации. При аттестации обязательно проверяется: наличие проектной документации, ее полнота, соответствие текущей реализации системы защиты этой проектной документации. Утверждаем, что данные вопросы очень важны, поскольку подготовка к аттестации позволяет обеспечить информационную безопасность. 

Анализ уязвимостей информационной системы и принятие мер по их устранению. При аттестации систем проводится в обязательном порядке. Более того, наличие неустраненных уязвимостей препятствует выдаче Аттестата, поэтому разработчики и компании, проводящие аттестационные испытания, уделяют этому самое пристальное внимание. 

Проверка сотрудников. Заключается в контроле того, что у поставщика облачного сервиса – оператора информационной системы есть подготовленные специалисты и что они обладают реальными(!) знаниями и опытом. Результаты проверки отражаются в протоколах, которые также передаются регулятору. Очевидно, что подготовленные и опытные специалисты, которые прошли все стадии подготовки и проведения аттестации, могут не только предоставлять облачный сервис 2FA, но и оказывать заказчику даже более специфические, более сложные консалтинговые услуги, нежели чем сотрудники у поставщика обычного 2FA сервиса. 

Внедрение системы обеспечения информационной безопасности. Данный этап предшествует процессу аттестации. Включает в себя проектирование системы и разработку ОРД, анализ рисков, установку и настройку необходимых средств защиты информации, их функциональные испытания, анализ уязвимости, опытную эксплуатацию, приемо-сдаточные испытания и перевод системы в промышленную эксплуатацию. Все это также тщательно документируется и предоставляется регулятору для проверки.

В самом общем случае, у поставщика облачного сервиса может быть проведена как аттестация, так и оценка соответствия, где просто декларируется внедрение мер обеспечения безопасности. Когда с потенциальным заказчиком будет подписано соглашение о неразглашении (англ. Non Disclosure Agreement, NDA), то ему может быть предоставлена информация какими способами и средствами эта безопасность обеспечивается. Запросите эти документы и проанализируйте полученную информацию, и тогда вы сможете убедиться в надежности, качестве и доступности облачного сервиса, который планируете использовать.

Сегодня мы поговорили об облачном сервисе двухфакторной аутентификации на базе сертифицированного решения. Обсудили для каких информационных систем он предназначен и в чем заключается его специфика. Следующую статью мы предложим поставщикам облачных ИТ-услуг. Поговорим об ожиданиях и предпосылках включения многофакторной аутентификации в портфель облачных сервисов, о потребностях компании при развертывании и продвижении таких сервисов, о технологической основе сервисов 2FA и необходимой экспертизе для развертывания и оказания таких сервисов.

Дата публикации: 16.04.2024