Для будущих учащихся на курсе «Microservice Architecture» подготовили традиционный перевод материала.Также всех желающих приглашаем на открытый вебинар по теме «Распределенные очереди сообщений на примере кафки». Микросервис — это структурная единица, в которой все данные и функции, относящиеся к какой-нибудь одной конкретной бизнес-цели, объединены в один сервис. Что ж, это достаточно общее понимание микросервиса, но что мы на самом деле под ним подразумеваем? Для примера мы можем взять конструктор Lego, да, вы не ослышались, Lego. Возможно, вы помните, что когда мы играем с Lego, мы начинаем сборку конструкции с одного отдельного кирпичика Lego. Точно так же, как каждый кирпичик Lego обособлен от других, каждый микросервис независим, но является составным элементом, из которых создается нечто большее. Здесь мы можем провести наглядную параллель между микросервисом и кирпичиком Lego. Изолированность Масштабируемость Производительность  Гибкость  Более быстрая разработка проекта Эволюционность Существует еще много преимуществ и возможностей микросервисов, но мы отложим разговор о них на следующий раз. В этой статье мы обсудим шаблоны безопасности микросервисов. В мире микросервисов очень широко используется термин «API-led архитектура». API-led архитектура подразумевает, что мы разбиваем все наше приложение на разные уровни API в зависимости от области их функциональности. Так мы приходим к концепции многоуровневой защиты. Вводя различные уровни в приложение, мы также вводим API-шлюзы (API-gateways) для каждого уровня. Наличие нескольких шлюзов API затрудняет проникновение потенциального хакера вглубь системы из-за разного набора AuthN и AuthZ политик для каждого уровня. Токен доступа — это объект, инкапсулирующий удостоверение безопасности процесса или потока. Он содержит учетные данные безопасности для сеанса входа в систему и идентифицирует пользователя, группы пользователей, привилегии пользователя и, в некоторых случаях, конкретное приложение. OAuth и OpenID — конкретные реализации этой концепции. SAML является открытым стандартом, который позволяет провайдерам удостоверений передавать учетные данные авторизации для поставщиков услуг. С SAML вы можете использовать один набор учетных данных для входа на множество разных сайтов. Управлять одним логином для каждого пользователя намного проще, чем управлять отдельными логинами для каждой учетной записи, которая у вас есть. JWT — это открытый стандарт, определяющий компактный и автономный способ безопасной передачи информации между сторонами в виде JSON-объекта. Эту информацию можно проверить и доверять ей, потому что она имеет цифровую подпись. JWT могут быть подписаны с использованием секрета (с алгоритмом HMAC) или пары публичного/приватного ключей с использованием RSA. 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: SSL — это протокол для защищенных соединений трафика. Благодаря использованию SSL протокол HTTPS предотвращает доступ злоумышленников и перехватчиков к службам веб-приложений. HTTPS — это, по сути, HTTP через SSL. SSL устанавливает зашифрованное соединение с использованием SSL-сертификата, который также известен как цифровой сертификат (digital certificate). Узнать подробнее о курсе «Microservice Architecture». Смотреть открытый вебинар по теме «Распределенные очереди сообщений на примере кафки». Редактор