Заметка №2 Как правильно разместить сегмент ИСПДн на территории дата-центра и не разгневать Роскомнадзор?
Продолжу цикл статей про создание распределенной ИСПДн, сегмент которой располагается на территории сторонней организации. Предыдущую часть вы можете прочитать здесь. Если лень перечитывать, то в предыдущей статье, я рассматривала услугу «Хостинг конфиденциальной информации», к сожалению, она не оправдала всех моих надежд и не смогла выполнить все требования 152-ФЗ и подзаконных актов в области защиты ПДн 😥 . Я начала дальше искать варианты, как разместить веб-сервер и сервер с СУБД на ресурсах сторонних компаний, снять ответственность за администрирование и поддержание работоспособности сайта с Заказчика и выполнить требования по защите ПДн в полном объеме.
Решение нашлось очень быстро!
Существует множество хостинг-компаний, которые предоставляют услугу Web Hosting Dedicated Server. Web Hosting Dedicated Server — это выделение отдельного физического сервера целиком для конкретного проекта. Не путать с услугой VPS (VDS), когда предоставляется виртуальный выделенный сервер, в нашем рассматриваемом случае хостинг-компании предоставляют полностью отдельный физический сервер целиком в аренду каждому клиенту. В телефонной беседе ни один из операторов различных хостинг-компаний не был против установки необходимых нам программных средств защиты информации. Соответственно с установкой сертифицированных средств защиты от несанкционированного доступа, систем обнаружения вторжений, средств антивирусной защиты и межсетевого экранирования проблем не возникнет. Остается только реализовать защищенное соединение между двумя сегментами ИСПДн для обмена информацией. На рисунке ниже я привела пример построения такого соединения на основе линейки сертифицированных средств защиты ViPNet.
Остается только грамотно в договоре с хостинг-компанией прописать ответственность перед Заказчиком за соблюдение конфиденциальности персональных данных, обрабатываемых в сегменте хостинг-компании.
Теперь обратим внимание на еще один важный вопрос. В соответствии с положениями 21 приказа ФСТЭК в ИСПДн должны быть реализованы требования по идентификации и аутентификации субъектов доступа к объектам доступа. То есть идентификация и аутентификация пользователей веб-сайта при входе в личный кабинет должны выполнятся сертифицированными средствами защиты информации. Логично предположить, что в данном случае Secret Net нас не спасет 🙂 . В следующей заметке я кратко распишу, в каких случаях надо сертифицировать функционал специального программного обеспечения, отвечающего за идентификацию и аутентификацию пользователя на сайте, а в каких случаях необходима сертификация СУБД. А также будет рассказан маленький «чит» как в данной ситуации полностью или частично отказаться от использования сертифицированных средств защиты информации, а также от необходимости сертификации функционала СПО/СУБД.
Про личный кабинет, можно наверное как-то обезличить данные тогда не потребуется лишней защиты воротить?
Вы абсолютно правы, обезличенные ПДн-нет проблем! Однако в рассматриваемой мной задаче ПДн не являются обезличенными. И поэтому приходится воротить целый огород. Например, те же Госуслуги, там обезличенными ПДн не отделаешься…
Анастасия, а Вы как выяснили, что та «не оправдала»?
Возможно Вам стоит ознакомится с моей предыдущей статьей:
http://s3r.ru/28/10/2013/zakonodatelstvo/zametka-1-hosting-konfidentsialnoy-informatsii-panatseya-ot-152-fz-ili-dengi-na-veter/
Там всё подробно написано, да и сами операторы компании, предоставляющей услугу нас своем сайте написали, что они выполняют только ряд требований 152-ФЗ. Выделенный сервер они не предоставляют, и на одном их физическом сервере образуется «свалка» из «конфиденциальной информации» разных Заказчиков, которая лежит вся в перемешку, а сверху на это прилеплен сертифицированный антивирус…
«Свалка вперемешку» — это художественная литература.
Какое СРД находилось (или могло бы быть вставлено) между ИСПДнами разных заказчиков в прошлый раз? Никакое? Неправда.
Какое СРД разделяет их в этот — сертифицированный МСЭ? Тоже нет.
Так что же изменилось в разделении ИСПДнов? Чур, в терминах ЗИ.
В данных двух статьях рассматривается не рассматривается вопрос управления доступом субъектов доступа к объектам доступа, а вопрос разделения закрытых сегментов с конфиденциальной информации от открытых сегментов (с информацией, которая для нас не является конфиденциальной). Я, как Оператор ПДн, передаю БД с собранными мной ПДн на обработку третьему лицу-компании Обработчику. Ответственность перед субъектом ПДн за защиту его ПДн несет Оператор. Оператор, отдавая конфиденциальную информацию Обработчику, должен быть уверен, что все требования по защите ПДн Обработчик один или совместно с Оператором будет выполнять ПОЛНОСТЬЮ. Одним из таких требований является то, что информация разного уровня конфиденциальности не может обрабатываться вместе. Т.е. нельзя на одном сервере хранить информацию с грифом «Секретно», «Сов. секретно» и иную информацию конфиденциального характера. В случае с данной услугой на одном сервере хранятся БД разных Заказчиков с разным уровнем конфиденциальности. Создавая систему защиты ПДн я, как оператор, должна быть точно уверена, что мой сегмент с моей конфиденциальной информацией должен быть отделен от сети общего пользования и других сегментов с «чужой информацией» сертифицированными средствами межсетевого экранирования. В первой статье моя БД не будет отделена от других БД межсетевым экраном, во второй статье моя БД отделена от остального сегмента и сетей общего пользования программным межсетевым экраном VipNet Client. Также для реализации требований к разным уровням защищенности может потребоваться использование дополнительных программных средств защиты. Так почему же я должна устанавливать МОИ средства защиты на сервер, которые обрабатывает, помимо моей конфиденциальной информации, ЧУЖУЮ? Надеюсь я смогла ответить на Ваш вопрос полностью.
И это мы еще не обсуждали вопрос наличия у компании, предоставляющей данную услугу Лицензии на техническую защиту конфиденциальной информации.
Например, компания, предоставляющая такую услугу должна осуществлять контроль защищенности конфиденциальной информации от несанкционированного доступа и ее модификации в средствах и системах информатизации, а на это требуется лицензия по ТЗКИ. В случае, если в договоре с Заказчиком компания берет на себя обязательства по защите конфиденциальной информации и еще получает за это прибыль, то необходима лицензия на ТЗКИ. А за услугу «Хостинг конфиденциальной информации» деньги берут, а вот сканов этой лицензии я нигде не нашла…
Слишком много пробелов и недостатков получается. Я бы не стала использовать в своих проектах данную услугу, но это исключительно моё мнение.
UP. Поводу лицензии, она есть № 1594 от 20.09.2011г. на деятельность по технической защите конфиденциальной информации Федеральной службы по техническому и экспортному контролю!
Тогда вообще не ясно, почему, имея такую отличную лицензию, нельзя каждому клиенту выделять не место на сервере, где всё вперемешку, а отдельный сервер с программным межсетевым экраном. Отличная услуга была бы… Каждый бы сам тогда доустанавливал необходимые ему средства защиты на арендуемый сервер, и имел бы выделенный сегмент ИСПДн на территории сторонней компании с лицензией на ТЗКИ, которая осуществляла бы обслуживание серверного оборудования, экономя ресурсы клиента. Почему не довести до ума?
По поводу Хостеров лицензиатов по ТЗКИ 2 примера:
http://onlanta.ru/about-company/certificates/
http://www.parking.ru/Attachment.aspx?Id=510
Меня больше интересует вопросы:
1. Как может реализовываться мера ЗИС.3 из приказа 21 в случае передачи данных от сервера до клиента (тот же личный кабинет), в случае актуальности соответствующих угроз? (https не имеет сертификата, а каждому клиенту не поставишь клиента скзи)
2. В случае размещения у Хостера, который не является владельцем ЦОДа и уж тем более лицензиатом ФСТЭК ФСБ вообще варианта хоть как то вылезти нет?
3. Допустим, инет магаз. или иной сервис не желает обрабатывать фио, ему достаточно id, №тел, и емайл? Требуется ли защищать такие (возможно обезличенные) ПДн?
Павел, спасибо большое за ссылки, буду иметь ввиду!
Теперь к ответам:
1. В политике безопасности на сайте мы прописываем, что канал передачи данных от клиента до сервера не является защищенным, и все риски субъект ПДн берет на себя. Потому что вы правильно говорите, что каждому клиенту СЗИ не поставишь. Данный пункт политики не будет противоречить ФЗ-152 и прочим подзаконным актам в области ПДн.
2. Не очень поняла суть вопроса, переформулируйте пожалуйста.
3. id, e-mail, номер телефона, на мой взгляд, не позволяют однозначно идентифицировать субъекта персональных данных (при регистрации e-mail можно указать ложные данные, телефон оформить на другого человека или вообще указать служебный номер). То есть этот набор относится к обезличенным. Обезличенные и общедоступные ПДн защищать не требуется.
Как можно возложить риски на субъекта ПДн? Таким образом его можно и обязать реализовывать некие меры! Желаю видеть живой пример такого перекладывания рисков после проверки РКН. Если я правильно понимаю фз152, обязанности по защите лежат на операторе ПДн и субъект тут выступает лишь как заинтересованное лицо без ответственности и обязанностей.
Уточняю вопрос 2. В случае если все же произошло размещение в ЦОДе, получится ли написав «корректную» модель угроз и возложив часть ответственности на ЦОД посредством договора, уйти от реализации «дорогих » мер? Честно скажу, использовать «защищенные» ЦОДы дорого.
Непонятно исходя из каких нормативных документов обезличенные и общедоступные ПДн защищать не требуется? Если приходит РКН, то на какой документ ссылаться будем? Ведь это тоже ПДн, а раз ПДн то требует защиты.
Ко 2-ому вопросу. На «незащищенный» ЦОД мы на договорной основе можем возложить ответственность только за то, что в пределах контролируемой зоны (территории ЦОДа) никто не сможет осуществить попытку несанкционированного доступа к нашему оборудованию, обрабатывающему ПДн (неважно арендуется оно или находится в собственности).
Допустим от сотрудников ЦОДа нам нужно, только чтобы они поддерживали работоспособность оборудования и обеспечивали бесперебойное питание и доступ в Интернет. А администрирование средств защиты мы оставляем себе. В таком случае ЦОД не осуществляет никакой деятельности по ТЗКИ и лицензия ФСТЭК для ЦОДа не требуется. Но Оператор своими силами устанавливает, настраивает и администрирует все средства защиты в соответствии с УЗ ИСПДн. Возможно так будет дешевле. Как раз в этой статье и рассмотрен пример размещения сегмента ИСПДн в «простом» ЦОДе.
Про риски пользователя: мы не можем запретить передавать пользователю свои ПДн нам по открытым каналам связи. Пока ПДн не поступили к нам на сервер — мы их не обрабатываем, то есть для субъекта ПДн мы не являемся пока Оператором, соответственно мы обязаны только уведомить пользователя о том, что он передает нам свои ПДн по открытым каналам связи, а после поступления их к нам на сервер, мы уже предпринимаем все меры по защите ПДн согласно 152-фз и подзаконным актам. Субъект ПДн волен сам передавать свои ПДн куда угодно и кому угодно по открытым каналам связи, это его конституционное право. Также, если субъект не хочет передавать свои ПДн по открытым каналам связи, он может от этого отказаться. Тут главное тот момент, что субъект до передачи нам ПДн уведомлен о том, что до момента поступления нам его ПДн, ответственность за них несет он сам (прописать в политике безопасности сайта).
Про обезличивание:
персональные данные — любая информация, относящаяся к прямо или косвенно определенному или определяемому физическому лицу (субъекту персональных данных).
обезличивание персональных данных — действия, в результате которых становится невозможным без использования дополнительной информации определить принадлежность персональных данных конкретному субъекту персональных данных.
Такого понятия, как обезличенные ПДн в законодательстве не существует. Получается, что после обезличивания мы получаем некую информацию, принадлежность которой к субъекту ПДн определить не возможно. Смотрим определение ПДн — там четко прописано, что ПДн — это некая информация, которая относится к субъекту ПДн. Следовательно после обезличивания мы получаем не ПДн, а иную информация, которую следует относить к конфиденциальной и защищать в соответствии с требованиями Вашей организации.
Можно ознакомиться с такой статьей http://infosec-irk.ru/articles/anonymous
Она немного устарела, но смысл похож. В данном направлении закон можно трактовать по-разному. Главное суметь это грамотно доказать РКН при проверке.
Спасибо за комментарии.