План на 2013 год: облако, данные и безопасность больше нельзя обсуждать по отдельности

Когда компания начинает проект по переносу данных в облако или внедрению новой аналитической платформы, обычно происходит одно из двух. Либо безопасность вызывают "в конце, чтобы проверить". Либо вопрос данных откладывают до тех пор, пока архитектура уже не устоялась и менять что-то поздно.

Оба сценария дороги. И с 2013 года они будут обходиться ещё дороже - потому что регуляторное давление растёт, инциденты становятся публичными, а цена ошибки в проектировании уже не растворяется в "мы потом исправим".

Почему эти три темы срослись

Ещё несколько лет назад можно было держать ИТ-инфраструктуру, управление данными и информационную безопасность как три отдельных ведомства. Каждое со своим бюджетом, своим языком и своими приоритетами.

Облако это сломало. Когда данные уходят за периметр - к провайдеру, в SaaS-сервис, в API партнёра - граница ответственности перестаёт совпадать с границей контура. Архитектурное решение "где хранить данные" автоматически становится решением по безопасности. И наоборот: правило безопасности "вот это хранить нельзя снаружи" напрямую формирует архитектуру.

Данные при этом - общее основание для обоих. Без понимания того, что именно хранится, откуда берётся и куда идёт, ни архитектура, ни защита не могут быть спроектированы корректно.

Что происходит, когда разговоры идут раздельно

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

Я видел и обратное: служба безопасности блокировала передачу данных между системами так, что аналитика становилась физически невозможной. Не из злого умысла - просто правила были написаны без понимания того, как данные используются.

Это не проблема людей. Это проблема структуры разговора.

Как должно выглядеть совместное планирование

На старте любого проекта, где данные куда-то движутся или где появляется внешний контур, нужно задать три блока вопросов одновременно:

По архитектуре: где физически будут жить данные, какие компоненты будут обрабатывать их в движении, какие зависимости появятся от внешних сервисов?

По данным: что именно это за данные, есть ли среди них персональные или чувствительные, кто является их владельцем и кто несёт ответственность за их корректность?

По безопасности: какие из этих данных подпадают под ограничения, кто имеет право доступа на каждом этапе, что происходит при инциденте и кто об этом узнает первым?

Ответы на эти вопросы влияют друг на друга. Поэтому обсуждать их нужно в одной комнате.

Практические следствия для плана на 2013 год

Если в вашей компании на следующий год запланированы проекты с переносом данных, новыми облачными сервисами или интеграциями с партнёрами - стоит сделать несколько вещей заранее:

• убедиться, что ИБ-специалист включён в проектирование с самого начала, а не приглашается на приёмку;
• провести быстрый аудит того, какие данные и где сейчас хранятся - не чтобы всё переделать, а чтобы знать с чем работаете;
• зафиксировать, какие категории данных компании нельзя выносить за периметр ни при каких условиях - это граница, которую архитектура обязана уважать;
• проверить контракты с облачными провайдерами: где физически стоят серверы, какие обязательства по уведомлению об инцидентах, что происходит с данными при расторжении договора - и думать о выходе из облака до того, как в него войти.

Это не паранойя и не бюрократия. Это базовая гигиена проекта, которая в 2013 году перестаёт быть опциональной.

Один диагностический вопрос

Попросите любого человека в вашей компании ответить: "если завтра мы захотим сменить облачного провайдера, что именно нам для этого нужно будет сделать?" Если ответа нет - значит, архитектура, данные и безопасность ещё не обсуждались как единая система. И это стоит исправить до старта следующего большого проекта, а не в его середине.