Когда компания выбирает облачную систему для документов, она смотрит на функции, цену, интерфейс и сроки внедрения. Всё это можно потрогать: функции показывают на демо, интерфейс открывают в браузере, сроки пишут в договоре. А вот где эти документы будут физически лежать, кто из сотрудников провайдера сможет к ним подойти и что происходит с этой инфраструктурой в три часа ночи — не спрашивает почти никто.
И людей тут винить не в чем. Инфраструктуру не показывают на демо. Её вообще нельзя увидеть: провайдер расскажет о ней ровно то, что сам решит рассказать, а проверить это со стороны нечем. Поэтому вопрос тихо выпадает из разговора — не потому что он неважный, а потому что непонятно, как его задавать и что делать с ответом.
Получается странная картина. Бумажный экземпляр договора запирают в шкаф, ключ от шкафа лежит у одного человека, а вынос документа из кабинета считается происшествием. Тот же самый договор в электронном виде отдают наружу — компании, о внутренней кухне которой известно ровно столько, сколько написано у неё на сайте. И это никого не смущает, потому что происходит буднично: нажали «загрузить», документ уехал.
Мы двадцатый год работаем с документами — самым чувствительным, что есть у организации, — и видим этот разрыв с другой стороны. Поэтому дальше будет две вещи. Сначала четыре вопроса, которые стоит задать любому облачному провайдеру, включая нас; ответы на них проверяемы, в отличие от обещаний. Потом — как на эти вопросы отвечаем мы сами.
Где физически лежат данные
Ответ «в облаке» ответом не является. Облако — это чей-то конкретный дата-центр в конкретной стране, и от того, в какой именно, зависит, чьё законодательство к вашим документам применяется и кто может получить к ним доступ по запросу, минуя вас.
Правильный ответ звучит скучно и проверяемо: название и уровень дата-центра, страна, и отдельно — покидают ли данные её пределы хоть на каком-то этапе обработки. Последнее важнее, чем кажется: данные могут храниться в одной стране, а обрабатываться в другой — резервные копии, аналитика, работа языковых моделей. С появлением ИИ этот вопрос стал острее, потому что модель, которой отдают документ на обработку, физически живёт на чьих-то вычислительных мощностях, и эти мощности могут стоять совсем не там, где хранилище.
Кто из ваших сотрудников может подойти к моим данным
Этот вопрос задают реже всего, а он самый неудобный. У любого облачного провайдера есть инженеры, и у этих инженеров по определению есть доступ к инфраструктуре, на которой работает ваша система. Вопрос не в том, есть ли доступ, — вопрос в том, как он устроен.
Спрашивать стоит конкретно: доступ выдаётся навсегда или на срок; ограничен ли он конкретным адресом и портом или открыт целиком; пишется ли каждое подключение в журнал; и может ли провайдер показать вам этот журнал по вашему контуру. Ответ «у нас работают проверенные люди» — не ответ, а уход от вопроса. Проверенные люди тоже увольняются, и вопрос в том, гаснет ли доступ вместе с ними сам или это кто-то должен вспомнить руками.
Кто смотрит на события безопасности и когда
Любая инфраструктура постоянно рассказывает о себе: серверы сообщают о нагрузке и месте на дисках, сетевые экраны — о заблокированных и пропущенных запросах, сама система — о том, кто какие документы открывал. Всё это стекается в отдельный инструмент, его называют SIEM — система сбора и корреляции событий безопасности.
Здесь и находится место, которое обычно не выдерживает проверки. SIEM только собирает. Дальше эти события должен кто-то живой просматривать и отделять настоящую атаку от обычного шума, а поток там такой, что в одиночку его не разбирают: за сутки набегают десятки тысяч записей. Подразделение, которое этим занимается, называется SOC — центр мониторинга безопасности. И вот ключевая деталь: круглосуточный SOC — это не один дежурный, а команда из нескольких человек, потому что смена не может длиться сутки. Содержать её дорого, поэтому у многих компаний ночью и в выходные в эти события не смотрит никто, а утром понедельника разбирают то, что накопилось за выходные.
Спрашивать стоит именно так: кто смотрит, в какие часы, и что происходит в ночь с субботы на воскресенье.
Через сколько я узнаю, если что-то случится
Ни один провайдер не даст стопроцентной гарантии безопасности — взламывают и Google, и Microsoft. Поэтому честный разговор идёт не о гарантии, а о том, что будет после.
И здесь я не назову вам число часов, хотя соблазн есть. Число, не записанное в договоре, — это не обязательство, а слова, а верить на слово в век ИИ никому нельзя, включая нас.. ) Поэтому вопрос звучит так: в каком пункте договора зафиксирован срок уведомления об инциденте и что именно вам сообщат — факт, затронутые данные, предпринятые действия. Если в договоре про это нет ничего, то отсутствие пункта и есть ответ. Задайте этот вопрос нам — и всем остальным заодно.
Как отвечаем мы
Где лежат данные. Все данные наших клиентов хранятся и обрабатываются в дата-центрах на территории Казахстана и не уходят за пределы страны. Это касается и хостинга, и вычислительных мощностей для работы моделей — локализация полная, дата-центр уровня Tier III.
Кто из наших инженеров может подойти. Доступ к инфраструктуре построен по многоуровневой модели: VPN, офисная сеть, защищённый шлюз, и только потом облачная инфраструктура. Доступ к конкретной системе выдаётся не навсегда и не целиком: он открывается по заявке, ограничен конкретным адресом и портом и живёт не дольше 30 дней, после чего гасится сам. Каждое подключение и каждое административное действие пишется в журнал и уходит в SIEM. То есть на вопрос «кто из ваших сотрудников и когда имел доступ к нашему контуру» у нас есть ответ с датами, а не заверение.
Кто смотрит на события. Здесь мы поступили так же, как поступаем с остальной рутиной в компании: поставили на эту работу агента. SOC-агент сводит четыре потока — нагрузку серверов, события безопасности, веб-трафик и действия пользователей — в одну сводку с контекстом и приоритетом. Когда набор признаков складывается в инцидент, он сам его регистрирует и передаёт дежурному специалисту, не дожидаясь, пока это кто-то заметит. Ночь и выходные перестали быть дырой в наблюдении, и для этого не пришлось нанимать вторую и третью смену.
Дальше — три вещи, которые мы сознательно оставили как есть, потому что иначе получилась бы автоматизация ради автоматизации.
Первое: агент работает только на чтение и ничего в системах не меняет. Второе: вердикт по инциденту выносит человек — подтверждённая это атака, ложное срабатывание или ситуация для наблюдения, решает специалист по безопасности, и мы не отдаём это решение агенту. Третье, и оно важнее первых двух: если какой-то источник данных замолчал, агент не выдаёт тишину за спокойствие, а отдельно на это указывает. Большинство ложных ощущений безопасности рождается именно из молчащего датчика — в консоли пусто, событий нет, и кажется, что всё хорошо.
Сертификат — это фотография
В июне этого года мы в очередной раз прошли сертификацию по стандарту ISO/IEC 15408, его ещё называют Common Criteria. Это международная методика оценки безопасности: аккредитованная лаборатория изучает архитектуру системы, механизмы защиты, процессы разработки и тестирования и ищет уязвимости. По итогам присваивается уровень доверия — от первого, базовой проверки, до седьмого, формальной верификации для военных систем. Мы получили ОУД 4: проверяется не только сам продукт, но и то, как он спроектирован, написан и протестирован. Сертификат зарегистрирован в Государственной системе технического регулирования РК и действует до 2029 года.
Я им горжусь, и при этом отношусь к нему трезво. Сертификат — это фотография: он показывает, каким продукт был в дни испытаний. А безопасность живёт не в дни испытаний. Она живёт в три часа ночи в воскресенье, когда никто не смотрит, в день, когда уволился инженер с широким доступом, и в момент, когда кто-то торопится и делает исключение «только на сегодня». Поэтому сертификацию мы проходим — и работаем так, как будто её нет.
Сколько у вас сейчас облачных сервисов, в которых лежат корпоративные документы, и по скольким из них вы знаете ответ хотя бы на один из четырёх вопросов выше? Подозреваю, второе число сильно меньше первого — и это нормальная отправная точка, с неё начинали все.
