Облака в пейзаже. Как банку выбрать безопасного облачного провайдера?

BIS Journal №3(46)/2022

18 августа, 2022

Облака в пейзаже. Как банку выбрать безопасного облачного провайдера?

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

По данным исследования Data Bridge, среднегодовой рост мирового рынка облачных технологий в финансовом секторе с 2021 по 2028 годы составит 25%. И это неудивительно: 9 из 10 финансовых организаций в мире уже используют облака или планируют начать первые проекты в них в ближайшие полгода, говорит отчёт CSA.

По данным исследования IDC, банковский сектор в России является самым ёмким по потреблению облачных сервисов на горизонте до 2025 года. Однако не все банки готовы к переезду, а некоторые игроки рынка всё ещё настороженно относятся к облачным технологиям. Основные причины — требования информационной безопасности на фоне действующего законодательства и, как следствие, не до конца сформировавшиеся практика и критерии выбора безопасного облака.

 

ЗАЧЕМ БАНКАМ ОБЛАКА?

Прежде всего облака позволяют банкам улучшать показатель time-to-market. Кстати, самый распространённый сценарий применения облака в банках — перенос тестовых сред и сред разработки. При реализации этого сценария в облако не передаются персональные и другие чувствительные данные, поэтому финансовым организациям достаточно следовать внутренним регламентам по защите информации.

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

Облака также помогают банкам при переходе от монолита к микросервисам, что позволяет запускать на облачных мощностях отдельные продукты. Например, банк «Санкт-Петербург» не только создал в облаке среды разработки и тестовые среды, но и разместил сайт и приложение системы офферинга. В итоге показатель time-to-market вырос в 5 раз, экономия на инфраструктуре отдельных проектов составила 30%, а инвестиции в неё распределились на 3 года.

 

В целом облачные технологии в банковской отрасли позволяют:

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

 

РЕГУЛЯТОРНЫЕ ТРЕБОВАНИЯ И СУЩЕСТВУЮЩИЕ БАРЬЕРЫ

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

При переносе в облака систем, обрабатывающих персональные данные, требуется обеспечить соблюдение 152-ФЗ и соответствующих внутренних положений банка. Но наиболее сложный вопрос — передача банковской тайны поставщикам облачных услуг. Думаем, что в дальнейшем могут появиться уточнения в законодательстве и стандартизированные требования к обеспечению безопасности для облачных провайдеров, что позволит сократить существующие «серые зоны». В настоящее время на площадке Ассоциации Финтех готовятся предложения по этим вопросам.

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

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

При этом существует множество сценариев и задач, которые банки могут решать в облаке уже сейчас. Для этого необходимо учитывать требования к информационной безопасности финансовых организаций. К таковым можно отнести СТО Банка России «Обеспечение информационной безопасности организаций банковской системы РФ», СТО Банка России «УПРАВЛЕНИЕ РИСКОМ НАРУШЕНИЯ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ ПРИ АУТСОРСИНГЕ» и ГОСТ 57580.

Банку остаётся оценить риски использования облаков как один из элементов операционного риска и сформулировать свои требования к безопасному облачному провайдеру.

 

КАК ВЫБРАТЬ БЕЗОПАСНОЕ ОБЛАКО?

При выборе облачных провайдеров следует обращать внимание на их соответствие существующей и, по возможности, перспективной нормативной базе.

В первую очередь провайдер должен пройти оценку уровня соответствия по ГОСТ 57580. Необходимо учитывать, что Положение Банка России от 17 апреля 2019 г. № 683-П требует, чтобы кредитные организации обеспечивали уровень соответствия ГОСТ 57580 не ниже третьего, а с 1 января 2023 года — не ниже четвёртого уровня. Поэтому отдавать предпочтение стоит облачным провайдерам с четвёртым уровнем соответствия ГОСТ 57580 и обращать внимание на степень соответствия требованиям пятого уровня.

Безусловно, на критерии безопасности при выборе облака сильно влияют специфика задач и состав обрабатываемых данных. Но в большинстве случаев следует обращать внимание на следующие моменты:

  • Соответствует ли провайдер требованиям действующего законодательства, регулятора и индустриальным стандартам, в частности ФЗ-152, ГОСТ 57580, PCI. Важно обращать внимание не только на сам факт наличия аттестата, но и на детали, указанные в заключении. Например, на состав сервисов, которые прошли аттестацию. Соответствие данным нормам и стандартам на стороне провайдера позволит финансовой организации обеспечить соответствие своей системы, размещённой в облаке.
  • Соответствие стандартам, свидетельствующим о зрелости внутренних процессов облачной платформы. Например, наличие сертификатов соответствия ISO 27001, 27017 и 27018 показывает, что у провайдера налажены процессы обеспечения информационной безопасности, и наличие этих сертификатов у провайдера полезно для клиента облака с точки зрения оценки рисков его использования.
  • Наличие у провайдера инструкций и практик по вопросу разделения ответственности за обеспечение безопасности между клиентом и облачной платформой. Без этого достаточно сложно и долго можно будет заниматься аттестацией по ФЗ-152 или ГОСТ 57580 конечных сервисов или систем банка в облаке.
  • Обеспечение безопасности на всех этапах создания и предоставления облачных сервисов и соблюдение процессов безопасной разработки Security Development Lifecycle.
  • Открытость и прозрачность коммуникаций. Зрелые провайдеры не скрывают информацию об инцидентах и делятся данными о каждом случае на своём сайте, разбирают их причины и сообщают о предпринятых действиях.
  • Локализацию и полноту контроля над облачной платформой: наличие собственных ЦОД, организацию физической безопасности, долю облачных сервисов собственной разработки и их включение в Единый реестр российских программ для ЭВМ и БД.

 

ПРАКТИЧЕСКИЕ ВОПРОСЫ БЕЗОПАСНОСТИ

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

При моделировании угроз для систем и данных, размещённых в облаке, необходимо учитывать важную особенность: более размытый сетевой периметр, чем в инфраструктуре собственного ЦОДа. О размытости корпоративного периметра рассуждают уже не первый год. С приходом мобильности и удалённой работы стена файрволов на границах корпоративной сети уже не столь эффективно помогает защищаться от различных угроз, поэтому и стал набирать популярность подход Defense in Depth. Он организован таким образом, что одной угрозе противостоит набор средств защиты на разных уровнях. В условиях использования облачных сервисов размытость периметра увеличивается. Поэтому очень важно понимать и уметь применять на практике различные инструменты защиты данных, обрабатываемых в том или ином сервисе облака.

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

  • Администратор и любые привилегированные пользователи в облаке должны использовать многофакторную аутентификацию.
  • Принцип минимальных привилегий. Доступы у сотрудников должны быть только к тем сервисам, которые необходимы им для работы.
  • При расширении состава используемых облачных сервисов необходимо помнить, что любой дополнительный компонент в облаке может стать причиной уязвимости остальных. Поэтому нужно регламентировать процесс принятия решений об использовании новых инструментов или запуске новых облачных сервисов.
  • Централизованное управление пользователями. Система управления доступа в облаке должна быть связана с корпоративной системой управления учётными записями и доступом. Такой подход упрощает контроль доступа при увольнении или переходе работника в другой отдел.

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

  • Логическая и сетевая сегментация ресурсов облака. Помогает более гранулярно управлять правами и снижать влияние различных подсистем друг на друга.
  • Хорошо знакомая практика использования бастионов (или jump-северов) при доступе к виртуальным машинам по SSH или RDP.
  • Правильное использование доступных в облачной платформе ролей и полномочий для реализации принципа минимальных привилегий.
  • Продумать защиту от DDoS c помощью инструментов провайдера или внешних сервисов.
  • Шифрование данных. Зрелые облачные провайдеры предоставляют возможность шифровать данные ключом провайдера. Также можно использовать дополнительное шифрование ключом клиента или шифрование на уровне конечных приложений.
  • Организация мониторинга и анализа аудитных логов облачных ресурсов. При использовании облаков часть логов можно собирать привычным способом, например с агентов, установленных на виртуальных машинах. Но также стоит помнить, что облачная платформа также предоставляет аудитные логи по активностям, связанным с ресурсами платформы. Эти логи целесообразно подвергать мониторингу и различным корреляциям для своевременного выявления подозрительных активностей на уровне управления облачными ресурсами.

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

Стать автором BIS Journal

Смотрите также

Подписаться на новости BIS Journal / Медиа группы Авангард

Подписаться
Введите ваш E-mail

Отправляя данную форму вы соглашаетесь с политикой конфиденциальности персональных данных

27.01.2023
Хакер получил доступ к «чёрному списку» пассажиров Управления транспортной безопасности США
27.01.2023
Хакеры атакуют британских политиков и журналистов
27.01.2023
Деятельность Hive пресечена в результате совместной операции 13 стран
27.01.2023
«Магнитка» пройдёт при поддержке НКЦКИ
26.01.2023
Минцифры создаст Центр цифровой криптографии
26.01.2023
Процессы операционной надёжности должны обеспечивать не только ИБ и ИТ, но и менеджмент некредитных финансовых организаций
26.01.2023
Противодействие атакам социальных инженеров не является вопросом исключительно службы ИБ банка
26.01.2023
Всё о приватности — теперь в «Кибрарии»
26.01.2023
В Новосибирске UserGate в качестве разработчика первого отечественного щита от кибератак пригласили к участию в областном мультимедийном проекте
26.01.2023
FLAMAX и КГАСУ представили Рустаму Минниханову совместную разработку в сфере водоснабжения и систем безопасности

Стать автором BIS Journal

Поля, обозначенные звездочкой, обязательные для заполнения!

Отправляя данную форму вы соглашаетесь с политикой конфиденциальности персональных данных