Продолжаем рассказывать про обеспечение информационной безопасности при размещении систем в облаках.
Ранее мы уже обсудили вопросы законодательного регулирования ИБ и определили границы зон ответственности облачных провайдеров и клиентов.
В этой же статье будут рассмотрены следующие темы:
Как именно формулировать запрос на услуги облачного провайдера – что и как писать в ТЗ?
Какие пункты ТЗ способны непреднамеренно усложнить жизнь облачному провайдеру и нежелательно удорожить предложение?
Клиентский взгляд
Итак, взгляд на подготовку ТЗ со стороны клиента: чего же он может захотеть, и как это сформулировать, чтобы не возникло задержек или взаимонепониманий?
В конечном счете, клиент хочет пользоваться определенной IT-системой. Для этого нужны определенные ресурсы вендора и их администрирование. Эта система должна соответствовать определенным требованиям по безопасности. Для обеспечения необходимого соответствия могут потребоваться дополнительно аппаратные или программные средства защиты.
Сама система может уже в продуктивном или тестовом виде существовать или только разрабатываться. Во втором случае потребуются дополнительные мощности для разработки, первых внедрений и плавного перевода в продуктивный статус.
Для того, чтобы с первой попытки подобрать подходящего поставщика облачных услуг и быстро найти с ним общий язык, со стороны клиента нужно выполнить следующие пункты.
1. Перечень законов и стандартов, соответствие которым может потребоваться для размещаемой системы и ее процессов.
Если в процессе разработки и жизни системы требования могут изменяться, то имеет смысл сформулировать список тех, выполнение которых жизненно необходимо для начала работы, и отдельный список требований, соблюдение которых может потребоваться позже.
И здесь возможны варианты:
Провайдер может выполнить сразу все, и это не скажется критично на стоимости.
Провайдер сам планирует наращивать перечень требований, которым он соответствует, и ваши планы совпадут.
Провайдер может в любой момент предложить перевести вашу систему в соседнее облако, в котором выполняется больше различных стандартов.
Кроме того, важно понимать, что если провайдер вообще в своих услугах может выполнять множество стандартов и законов по информационной безопасности, это не означает, что каждая его услуга соответствует всем требованиям одновременно. Нередко бывает ситуация, когда облако, например, соответствует 152-ФЗ и PCI DSS, а вот услуга DBaaS – только 152-ФЗ, а S3 – только PCI DSS.
Поэтому все эти требования лучше сформулировать и обсудить заранее.
2. Определить уровни соответствия стандартов и законов:
Уровень защищенности для 152-ФЗ.
Класс системы для защиты государственных информационных систем.
Уровень защиты для финансовых систем (под ГОСТ Р 57580.1).
Целесообразно зафиксировать, какой же уровень соответствия для всех выбранных стандартов и законов требуется от облачного провайдера.
И здесь есть нюанс. Часто клиенту нужен какой-то не очень суровый уровень – например УЗ3 по 152-ФЗ. Он пишет формальное ТЗ на конкурс, в которое вносит условие, что провайдер должен обеспечить соответствие требованиям УЗ3 и подтвердить это каким-то документом. И вот сидит сотрудник провайдера, обеспечивающего, например, УЗ2 – и грустит. Потому что УЗ2, очевидно, более высокий уровень, чем УЗ3. Но по формальным критериям – такое облако не подходит, так как подтверждающий документ содержит упоминание УЗ2, а не УЗ3, требуемого по ТЗ. Сотруднику приходится делать запрос уточнений в соответствии с тендерной или закупочной процедурой о допустимости участия в конкурсе облака, обеспечивающего УЗ выше, чем требуемый в ТЗ. Поэтому в ТЗ целесообразно прописывать требование об обеспечении уровня соответствия стандарту «не ниже чем» тот уровень, который необходим системе клиента.
3. Определиться с тем, что именно ожидается от облачного провайдера.
Возможны как минимум следующие варианты:
Нужны только ресурсы в облаке. Средства защиты, лицензии, услуги по приведению в соответствие и подтверждению соответствия не нужны – это все будет выполняться как-то иначе и потом;
Нужны ресурсы в облаке и услуги по приведению в соответствие с ИБ и его подтверждению. Лицензии на средства защиты не нужны (уже закуплены или есть другой привычный поставщик);
Нужны ресурсы в облаке и лицензии (или оборудование) средств защиты. Услуги по приведению в соответствие и его подтверждение не нужны (уже есть другой консультант);
Нужны ресурсы в облаке, лицензии и оборудование средств защиты, услуги по приведению в соответствие и его подтверждению. В общем – полный комплект.
Во-первых – лучше уточнить, какой же перечень услуг требуется от провайдера. Нередко возникает ситуация, когда в ТЗ указан перечень требуемых ресурсов (процессоров, памяти и дискового пространства) и вписана лаконичная строка «размещаемая система должна соответствовать 152-ФЗ». А сотрудник провайдера пытается понять: какой из указанных вариантов имеется в виду. Просто предложить ресурсы в облаке – это явно не обеспечить соответствие системы, а посчитать стоимость дополнительных лицензий и услуг, исходя из требований к мощности невозможно.
Во-вторых, для каждого «этажа» услуги стоит прописать соответствующие требования.
Для ресурсов – и количество и перечень стандартов (законов) и уровня соответствия стандарту (закону).
Для средств защиты:
Перечень нужных средств защиты: антивирусы, межсетевые экраны, IPS…..
Количество требуемых средств защиты: количество лицензий антивируса, пропускная способность межсетевого экрана и IPS… Кроме того, для, например, антивируса важно понимать – на какую ОС его планируется устанавливать. Не любой антивирус можно поставить на ОС Linux, и даже, если какой-то антивирус можно поставить и на Windows и на Linux, - бывает, что нужны разные лицензии для ОС Windows и ОС Linux.
Желаемый уровень администрирования средств защиты. Возможно, клиент хочет получить только лицензии, а администрировать их будет самостоятельно. Или ему нужна возможность пользоваться ОС с установленным антивирусом и не заниматься его администрированием. В любом случае, провайдер может обеспечить обслуживание средств защиты, но не определение правил работы (мы на этом останавливались в предыдущей статье и еще раз разберем ниже).
Для услуг по приведению в соответствие и его подтверждению нужно описать процессы и саму систему. У многих провайдеров есть стандартные опросники, но как минимум нужно описать:
Что делает система, какие процессы выполняет.
Откуда в систему попадают данные, и куда передаются из системы.
Используются ли в защищаемом процессе другие субподрядчики, и зачем.
4. Разобраться с некоторыми усложняющими пунктами.
В первую очередь еще раз остановимся на функции по администрированию средств защиты силами провайдера.
Наиболее распространенными запросами являются:
Администрирование межсетевого экрана.
Администрирование антивируса.
Обновление систем.
Все три процесса вызывают сложности по одной и той же причине: функционал реализуется более или менее технически сложными специальными инструментами, администрированию которых нужно обучаться – то есть иметь специальных сотрудников. И именно это и побуждает клиентов передавать этот функционал на сторону провайдера.
Но все эти три процесса подразумевают определение некоторых правил работы и определенный объем ответственности за действия:
Провайдер не может знать, с какими серверами можно общаться по сети, а с какими – нельзя. То есть, политику межсетевого экранирования должен создавать клиент. А провайдер может выполнять заявки по открытию доступов на межсетевом экране и следить за его работоспособностью.
Провайдер может включить работу антивируса и даже настроить какую-то усредненную политику работы. Но часы проверок (а во время антивирусной проверки проверяемый ресурс может несколько подтормаживать) должен указать сам клиент. И чего провайдер точно не может сделать – это придумать порядок действий для тех случаев, когда антивирус опознает файл как вирус, а сотрудник клиента утверждает, что файл правильный и срочно нужен для работы. Ну и гарантировать, что антивирус поймает 100% вирусов – провайдер тоже не может (просто потому, что так не бывает).
-
Провайдер может устанавливать обновления по какому-то согласованному расписанию. Но он должен получить то самое расписание проверок, а также согласованные технологические окна, в которые серверы можно перезагружать. И чего провайдер точно не может гарантировать, так это то, что все ПО, работающее на обновляемых серверах, совместимо с обновлением.
Чтобы быть в этом уверенным, необходимо создавать тестовые среды, наполнять их тестовым ПО и данными, заранее тестировать обновление в тестовой среде. Потом кто-то от клиента, умеющий работать с ПО, должен проверить – пережило ли ПО обновление, давать провайдеру разрешение на установку обновлений на продуктивную среду. Также этот специалист со стороны клиента должен принимать решение о том, что же делать, если ПО в тестовой среде сломалось после обновления.
Во-вторых, нередко бывает, что в самом начале взаимодействия клиента и облачного провайдера от системы требуется невысокий уровень защиты (например, 152-ФЗ УЗ3), но с течением времени уровень защищенности может подняться (например, до УЗ2).
В этом случае, у клиента есть выбор:
Сначала защищаться в соответствии с требованиями, актуальными прямо сейчас (в нашем примере – УЗ3), а когда станет актуально – переделывать систему под новые требования (в нашем примере – УЗ2). Это, скорее всего, будет дешевле на старте, но стоимость усиления защиты когда-то «завтра» — непредсказуема. Да и может потребоваться остановка работы системы на время проведения работ по усилению.
Сразу защищаться по максимуму. Это проще спланировать, но дороже.
Сразу поставить дорогие и сложные в установке (т.е. требующие времени на внедрение) компоненты от более строгого уровня (в нашем примере – УЗ2), а более простые к внедрению компоненты закупить потом, когда потребуется. Чаще всего, это касается межсетевого экрана и IPS. Это компромиссный и по стоимости, и по сложности вариант.
В-третьих, существует некоторая трудность, актуальная только для российских стандартов по безопасности (152-ФЗ в первую очередь), и касающаяся применения сертифицированных средств защиты.
152-ФЗ не требует применения сертифицированных ФСТЭК средств защиты. Регламентируется применение средств защиты, «прошедших процедуру оценки эффективности мер защиты», и сертификация является одной из допустимых процедур.
Приказ ФСТЭК № 17 (защита Государственных информационных систем – ГИС), в свою очередь, как раз требует обязательного применения сертифицированных средств защиты.
А среди компаний, осуществляющих приведение в соответствие и аттестацию ИСПДн встречаются адепты обоих подходов. Таким образом, подход к применению именно сертифицированных средств защиты сильно зависит от применяемого стандарта (152-ФЗ или защита ГИС), а также от подхода, принятого в компании, осуществляющей приведение в соответствие и его подтверждение.
Если по каким-то причинам требуется применение именно сертифицированных средств защиты – то это надо явно указать в ТЗ.
В-четвертых, очень много путаницы возникает вокруг термина «аттестация».
Существует несколько способов подтверждения соответствия системы требованиям по безопасности: оценка эффективности системы защиты и аттестация системы защиты.
Термин «аттестация» допустимо применять к подтверждению соответствия следующим требованиям:
Требования по защите персональных данных (152-ФЗ и Приказ ФСТЭК России №21).
Требования по защите государственных информационных систем (Приказ ФСТЭК №17).
Требования по защите автоматизированных систем (древний документ РД АС, в котором, в том числе, определяются такие, иногда еще встречающиеся требования, как 1Г).
Из этого перечня – РД АС (защита по классу 1Г) – это некий исторический артефакт, ныне почти не применяемый. РД АС в существенной степени был заменен положениями Приказа ФСТЭК №17. 17-й приказ новее и лучше во всем, кроме защиты от акустических и электромагнитных способов утечки информации. Только вот защита от электромагнитных способов воздействия в современных ЦОД – практически не актуальна: слишком много оборудования, обслуживающего разных заказчиков в одних и тех же помещениях. В результате, чаще всего ЦОДы либо вообще не делают защиту от 1Г, либо при аттестации обосновывают невозможность утечки информации по электромагнитным каналам — то есть удаляют ту самую часть РД АС, которая оставалась уникальной относительно 17-го приказа ФСТЭК.
Справедливости ради должен отметить, что в России существует некоторое количество отраслей, для которых защита от ПЭМИН все еще может оказаться актуальной. Но это обычно очень серьезные системы, находящиеся под контролем очень серьезных сотрудников – они обычно отлично знают, зачем им РД АС. Да и ЦОДы они используют специфические.
Для ГИС аттестация обязательна. Тут вопросов нет.
А для ПДн и 152-ФЗ – аттестация является добровольной процедурой. К тому же, стоящей дополнительных денег и налагающей дополнительные требования: как минимум о неизменности системы.
Т.е. далеко не всем заказчикам реально нужна аттестация по 152-ФЗ. Обычно достаточно оценки эффективности.
Но если аттестация по 152-ФЗ действительно нужна, то аттестаторы достаточно часто склоняются к мнению, что система должна быть защищена сертифицированными средствами защиты.
Ну и требование в ТЗ, что размещаемая в облаке система должна быть аттестована сразу с момента размещения – невыполнимо вообще никак. Аттестация – это длительная процедура, занимающая некоторое время: в среднем 2-3 месяца. То есть, если клиент размещает какую-то систему в облаке и планирует ее аттестовать, то на практике:
Провайдер выделяет ресурсы.
Система переезжает в облако.
Клиент самостоятельно, или провайдер облака, или другой подрядчик (выделенный на работы по безопасности, например) устанавливает в системе средства защиты и настраивает их.
Ответственный за ИБ (в идеальных условиях это сам клиент) вызывает аттестатора.
Аттестатор проверяет систему, и выписывает аттестат.
Таким образом, если клиент хочет, чтобы размещаемая в облаке система была аттестована, то выполнимым требованием является следующее: «размещаемая в облаке система должна пройти процедуру аттестации по требованиям информационной безопасности, предъявляемым <указание стандарта и уровня> в срок, не превышающий N месяцев».
Кстати, понятия «сертифицирован на соответствие 152-ФЗ», вообще, не существует. Сертифицированными бывают только средства защиты. А системы – либо соответствующими, либо аттестованными.
И в-пятых, есть сложность с применением ГОСТ-VPN.
ГОСТ-VPN бывает двух видов:
Site-to-Site (между шлюзами);
Remote Access (между компьютерами с программным клиентом и шлюзом).
ГОСТ-VPN в данный момент может быть реализован на программном и аппаратном обеспечении нескольких производителей, и решения различных производителей не совместимы между собой.
Т.е. если клиент хочет получить ГОСТ-VPN, то нужно уточнить в ТЗ:
Какая реализация (Site-to-Site или Remote access) требуется.
Требуется только установка шлюза на стороне облака, или установка оборудования на стороне клиента (или пользователей клиента) тоже нужна.
Есть ли требования по совместимости шлюза на стороне облака с оборудованием на стороне клиента (актуально, если у клиента уже есть шлюз, или если клиент будет строить много разных VPN-тоннелей с разными контрагентами и хочется всю VPN-сеть построить на оборудовании одного производителя).
Требования к пропускной способности VPN-тоннеля.
Если необходимо ставить оборудование на территории клиента, или предоставлять программные клиенты – то сколько и куда?
В конечном итоге в ТЗ должны быть указаны:
Перечень желаемых облачных услуг.
Перечень применимых стандартов и требований по ИБ, с детализацией для каждой из облачных услуг.
Указанный уровень соответствия каждому из стандартов. Если применимо, то для каждой из услуг.
Детализация степени вовлеченности облачного провайдера в услуги безопасности: провайдер только дает ресурсы (IaaS), или поставляет также лицензии, или еще и устанавливает ПО и СЗИ, или администрирует установленное ПО и СЗИ.
Должен ли провайдер участвовать в процессе приведения в соответствие или сертификации или аттестации информационной системы клиента, или клиент займется этим процессом сам.
Если есть дополнительные требования к СЗИ (например сертификация ФСТЭК) — то эти требования.
Если есть необходимость защиты канала связи до систем или пользователей, находящихся вне облака и требования к этой защите — то эти требования.
Уточнение всего вышеуказанного в ТЗ к облачному провайдеру позволит существенно сократить время на проработку предложения и устранить возможность избыточных предложений.
Бывают, правда, совсем сложные сценарии, при которых клиенту нужно совместить требования многих стандартов, обеспечить катастрофоустойчивость, получать услуги по модели Pay-as-you-Go (PAYG, то есть по факту потребления), или все это вместе. Что делать в таком случае – мы расскажем в следующей статье.