Цифровые компании (технологические стартапы) создают большую часть своей технологической экосистемы собственными силами. За последние несколько лет произошло несколько инцидентов, связанных с утечкой доступа к этой экосистеме.

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

Цель

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

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

  • Пользователь БД и пароль
  • Ключ шифрования
  • Сертификаты
  • Учетные данные облачной платформы
  • Токен стороннего API

Вектор угрозы

С практической точки зрения мы можем наблюдать из прошлого инцидента, что вектор угрозы можно смягчить. А мы?

Чтобы ответить на этот вопрос, нам нужно определить вектор угрозы утечки доступа, который использовало приложение. Чтобы помочь определить, давайте посмотрим, как приложение было разработано и развернуто.

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

Скомпрометированная рабочая станция разработки

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

В случае компрометации рабочей станции злоумышленник может получить необходимые учетные данные и предпринять дальнейшие вредоносные действия.

Жестко закодированные учетные данные

В большинстве команд разработчиков git является наиболее распространенным репозиторием кода. Это помогает легко обмениваться кодом одного разработчика с другим. Если этот разработчик делает жесткий код, он также использует жестко заданные учетные данные. Добавление угрозы внутреннего злонамеренного использования доступа.

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

Инструмент развертывания скомпрометирован

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

Популярные инструменты CI/CD, такие как Jenkins и CircleCI, имеют встроенную функцию для хранения учетных данных. С точки зрения эффективности это круто. С точки зрения безопасности эта практика противоречит концепциям минимальных привилегий и разделения обязанностей. Тот, который управляет операцией развертывания, также управляет учетными данными. Большинство инструментов CI/CD не имеют адекватных мер безопасности, таких как RBAC и аудиты. Хотя нет никаких сомнений в том, что инструменты CI/CD крайне важны для быстрого роста цифрового бизнеса, это не лучший инструмент для управления учетными данными.

Рабочий сервер скомпрометирован

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

Анализ угроз

На всех этапах SDLC существует угроза утечки доступа.

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

Решение для хранения учетных данных

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

Работающая система Credential Storage может обслуживать несколько приложений. Эта гибкость позволяет различным приложениям извлекать только те учетные данные, которые им необходимы.

Взаимодействие с учетными данными как объектными данными следует модели AAA.

  • Аутентификация
  • Авторизация
  • Подотчетность

Правильная конфигурация Credential Storage с моделью AAA снизит угрозу утечки доступа из другого приложения.

Credential Storage как выделенная система сама по себе имеет вектор угроз, который необходимо устранить. Эта система будет основной системой среды компании. Реализация Credential Storage должна соответствовать модели безопасности CIA.

  • Конфиденциальность
  • Честность
  • Доступность

Поставщик хранилища учетных данных

Хранилище Harsicorp

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

Посетите https://www.vaultproject.io/ для получения дополнительной информации.

Менеджер секретов AWS

Secrets Manager от AWS — это решение на основе SaaS для хранения учетных данных. Наличие системы, работающей в облаке, позволяет нам переносить операционные усилия — эффективно выполнять требования модели CIA. Плата за использование AWS Secrets Manager зависит от количества ключей и запросов и является экономичной.

Посетите https://aws.amazon.com/secrets-manager/ для получения дополнительной информации.

Менеджер секретов GCP

Google Cloud Platform (GCP) предлагает хранилище учетных данных на основе SaaS под названием Secret Manager. Обладая полным облачным преимуществом в работе, Secret Manager очень дешев.

Проверьте https://cloud.google.com/secret-manager для получения дополнительной информации.

CyberArk Conjur

Conjur — это хранилище учетных данных с открытым исходным кодом от Cyberark. У него есть корпоративная версия для поддержки корпоративных компаний, у которых нет ресурсов для самостоятельного управления версией с открытым исходным кодом. Название предприятия — CyberArk Application Access Manager.

Проверьте https://www.conjur.org/ для получения дополнительной информации.

Выполнение

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

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

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

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

Технический контроль

Credential Storage — это всего лишь инструмент. Для обеспечения надлежащего уровня безопасности с помощью AAA требуется правильная настройка.

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

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

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

Административный контроль

Инструмент не может работать сам по себе без политики поддержки использования.

  • Создайте матрицу ролей, чтобы определить поведение взаимодействия с объектом. Создание RBAC с минимальными привилегиями в системе возможно только в том случае, если определена политика организации. Эта политика является результатом сотрудничества отдела кадров и отдела ИТ, чтобы обеспечить управление всеми ролями.

  • Запрет на распространение любых учетных данных на любых носителях. Мы можем лучше контролировать угрозы с помощью хранилища учетных данных. Но исследования показывают, что человек является самым слабым звеном в системе безопасности. Если один из сотрудников когда-либо распространит учетные данные, используя внешний канал связи, мы не можем гарантировать секретность этих учетных данных.

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

Вердикт

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