Распространенные шаблоны безопасности, используемые в большинстве архитектур API
Для будущих учащихся на курсе «Microservice Architecture» подготовили традиционный перевод материала.
Также всех желающих приглашаем на открытый вебинар по теме «Распределенные очереди сообщений на примере кафки».
Что такое микросервисы?
Микросервис — это структурная единица, в которой все данные и функции, относящиеся к какой-нибудь одной конкретной бизнес-цели, объединены в один сервис.
Что ж, это достаточно общее понимание микросервиса, но что мы на самом деле под ним подразумеваем?
Для примера мы можем взять конструктор Lego, да, вы не ослышались, Lego.
Возможно, вы помните, что когда мы играем с Lego, мы начинаем сборку конструкции с одного отдельного кирпичика Lego.
Точно так же, как каждый кирпичик Lego обособлен от других, каждый микросервис независим, но является составным элементом, из которых создается нечто большее.
Здесь мы можем провести наглядную параллель между микросервисом и кирпичиком Lego.
Преимущества использования микросервисной архитектуры
Изолированность
Масштабируемость
Производительность
Гибкость
Более быстрая разработка проекта
Эволюционность
Существует еще много преимуществ и возможностей микросервисов, но мы отложим разговор о них на следующий раз. В этой статье мы обсудим шаблоны безопасности микросервисов.
Шаблоны безопасности микросервисов
Многоуровневая защита (Layered Defense)
В мире микросервисов очень широко используется термин «API-led архитектура». API-led архитектура подразумевает, что мы разбиваем все наше приложение на разные уровни API в зависимости от области их функциональности.
Так мы приходим к концепции многоуровневой защиты. Вводя различные уровни в приложение, мы также вводим API-шлюзы (API-gateways) для каждого уровня.
Наличие нескольких шлюзов API затрудняет проникновение потенциального хакера вглубь системы из-за разного набора AuthN и AuthZ политик для каждого уровня.
Использование токенов доступа и идентификации (Access and Identity Tokens)
Токен доступа — это объект, инкапсулирующий удостоверение безопасности процесса или потока.
Он содержит учетные данные безопасности для сеанса входа в систему и идентифицирует пользователя, группы пользователей, привилегии пользователя и, в некоторых случаях, конкретное приложение.
OAuth и OpenID — конкретные реализации этой концепции.
Наиболее широко используемые токены
SAML (Security Assertion Markup Language — язык разметки декларации безопасности)
SAML является открытым стандартом, который позволяет провайдерам удостоверений передавать учетные данные авторизации для поставщиков услуг. С SAML вы можете использовать один набор учетных данных для входа на множество разных сайтов. Управлять одним логином для каждого пользователя намного проще, чем управлять отдельными логинами для каждой учетной записи, которая у вас есть.
JWT (веб-токен JSON) и семейство стандартов JOSE
JWT — это открытый стандарт, определяющий компактный и автономный способ безопасной передачи информации между сторонами в виде JSON-объекта. Эту информацию можно проверить и доверять ей, потому что она имеет цифровую подпись. JWT могут быть подписаны с использованием секрета (с алгоритмом HMAC) или пары публичного/приватного ключей с использованием RSA.
PASETO (Platform Agnostic SEcurity TOken — токен безопасности, не зависящий от платформы)
PASETO — это криптографически секьюрное, компактное и URL-безопасное представление заявленных значений, предназначенное для сред с ограниченным пространством, таких как файлы cookie HTTP, заголовки авторизации HTTP и параметры запроса URI. PASETO кодирует заявленные значения, которые должны быть переданы в JSON-объекте, и либо зашифровываются симметрично, либо подписываются с использованием публичного ключа.
Ключевое различие между PASETO и семейством стандартов JOSE (JOSE Standards Family) заключается в том, что JOSE позволяет разработчикам и пользователям сочетать и комбинировать их собственный выбор криптографических алгоритмов (указанных заголовком «alg» в JWT), тогда как PASETO имеет четко определенные версии протокола для предотвращения возможности выбора небезопасных конфигураций.
Безопасность с помощью кода
Здесь мы будем обсуждать основной стиль/стандарты написания кода API. Код каждого API должен быть написан таким образом, чтобы автоматически избегать всех возможных уязвимостей. Если избежать уязвимостей невозможно, то ваш API должен по крайней мере избегать 10 основных уязвимостей, представленных OWASP.
Сканирование зависимостей
Поскольку большинство современных API используют контейнерный подход для упаковки и развертывания API в облаке, очень важно сканировать все зависимости, которые будут использоваться для поддержки операций API.
Уязвимости, обнаруженные в образах Docker Hub:
Использование HTTPS
SSL — это протокол для защищенных соединений трафика. Благодаря использованию SSL протокол HTTPS предотвращает доступ злоумышленников и перехватчиков к службам веб-приложений. HTTPS — это, по сути, HTTP через SSL. SSL устанавливает зашифрованное соединение с использованием SSL-сертификата, который также известен как цифровой сертификат (digital certificate).
Узнать подробнее о курсе «Microservice Architecture».
Смотреть открытый вебинар по теме «Распределенные очереди сообщений на примере кафки».
