Как создать среду нулевого доверия в сфере финансовых услуг (Борис Бялек)

Не так давно специалисты по безопасности защищали свои ИТ примерно так же, как средневековые стражники защищали город-крепость — они максимально затрудняли проникновение внутрь. Но как только кто-то прошел за периметр, у него был широкий доступ
к богатству, содержащемуся внутри. В финансовом секторе это означает доступ к личной идентифицируемой информации (PII), которая включает в себя «рыночный набор данных» номеров кредитных карт, имен, информации социального обеспечения и многого другого. К сожалению, таких случаев много
где замок был взят штурмом, а конечные пользователи были в тени. Самый известный до сих пор

Эквифакс инцидент, где небольшая брешь привела к годам недовольных клиентов. 

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

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

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

Вот о чем вам нужно подумать, чтобы создать среду с нулевым доверием. 

Защита данных 

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

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

По мере того, как все больше финансовых учреждений переходят на облако, это может усложниться. Обязанности по обеспечению безопасности разделены между собственной организацией клиентов, поставщиками облачных услуг и поставщиками используемых облачных услуг. Это известно как
модель совместной ответственности. Это отходит от классической модели, в которой ИТ-отдел отвечает за защиту серверов и системы безопасности, затем необходимо повысить безопасность программного обеспечения — скажем, версии программного обеспечения базы данных, — а затем необходимо ужесточить фактический код приложения.
В этой модели аппаратное обеспечение (ЦП, сеть, хранилище) находится исключительно в сфере облачного провайдера, который предоставляет эти системы. Поставщик услуг для модели «Данные как услуга» затем доставляет защищенную базу данных клиенту с назначенной конечной точкой.
Только после этого настоящая клиентская команда, их разработчики приложений и команда DevOps вступают в игру для фактического «решения». 

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

Аутентификация для клиентов и пользователей 

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

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

Также следует учитывать беспарольную аутентификацию — не только для клиентов, но и для внутренних команд. Это можно сделать несколькими способами с помощью базы данных: либо автоматически сгенерированные сертификаты, необходимые для доступа к базе данных, либо
расширенные возможности для организаций, которые уже используют сертификаты X.509 и имеют инфраструктуру управления сертификатами. 

Ведение журнала и аудит 

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

Аудит на основе ролей позволяет вам регистрировать и сообщать о действиях по определенным ролям, таким как userAdmin или dbAdmin, в сочетании с любыми ролями, унаследованными каждым пользователем, вместо того, чтобы извлекать действия для каждого отдельного администратора. Такой подход упрощает
для организаций, чтобы обеспечить сквозной операционный контроль и поддерживать понимание, необходимое для соответствия и отчетности. 

Шифрование 

Имея большие объемы ценных данных, финансовые учреждения также должны убедиться, что они используют шифрование — при передаче, хранении и даже при использовании. Защита данных с помощью шифрования на уровне поля на стороне клиента позволяет перейти к управляемым службам в
облако с большей уверенностью. База данных работает только с зашифрованными полями, и организации контролируют свои собственные ключи шифрования, а не поставщик базы данных. Этот дополнительный уровень безопасности обеспечивает еще более точное разделение
обязанностей между теми, кто использует базу данных, и теми, кто ее администрирует и управляет ею. 

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

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