Микросервисы для разработчиков Java: управление безопасностью и секретами

1. Введение

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

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

Содержание

1. Введение
2. Вниз к проводу
3. Безопасность в браузере
4. Аутентификация и авторизация
5. Поставщики удостоверений
6. Защита приложений
7. Хранение секретов в безопасности
8. Забота о ваших данных
9. Сканируйте свои зависимости
10. Упаковка
11. Следите за своими журналами
12. Оркестровка
13. Запечатанное Облако
14. Выводы
15. Что дальше

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

2. Вниз к проводу

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

Использование безопасного транспорта, вероятно, является наиболее фундаментальным способом защиты данных в пути от их перехвата или подделки. Для связи через Интернет это обычно означает использование HTTPS (или, точнее, HTTP поверх SSL / TLS ) для защиты конфиденциальности и сохранения целостности данных. Интересно, что хотя для HTTP / 2 наличие защищенного транспорта все еще является необязательным, оно в основном используется исключительно с SSL / TLS .

Помимо только HTTPS , существует множество других протоколов, которые используют TLS для защиты связи, например, DTLS , SFTP , WSS и SMTPS . Также стоит упомянуть Message Security Layer , расширяемую и гибкую инфраструктуру безопасного обмена сообщениями, которая была открыта из Netflix .

3. Безопасность в браузере

На стороне веб-браузера много усилий направлено на то, чтобы сделать веб-сайты более безопасными, поддерживая такие механизмы, как HTTP Strict Transport Security ( HSTS ), HTTP Pinning Public Key ( HPKP ), Content Security Policy ( CSP ), безопасные куки и файлы cookie того же сайта (некоторые из них наверняка будут полагаться на веб-порталы клиентов и администрации JCG Car Rentals ).

Что касается сценариев, у нас есть спецификация API веб-криптографии, которая описывает API JavaScript для выполнения основных криптографических операций в веб-приложениях (хеширование, генерация и проверка подписи, а также шифрование и дешифрование).

4. Аутентификация и авторизация

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

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

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

Что касается авторизации , то в основном существуют две преобладающие модели: управление доступом на основе ролей (также называемое RBAC ) и списки контроля доступа ( ACL ). Как мы увидим позже, большинство платформ безопасности поддерживают обе эти модели, поэтому необходимо принять взвешенное решение, которое лучше всего соответствует контексту вашей микросервисной архитектуры .

Если мы переместим аутентификацию и авторизацию в сторону веб-приложений и сервисов, как с нашей платформой JCG Car Rentals , мы, скорее всего, получим два отраслевых стандарта: OAuth 2.0 и OpenID Connect 1.0 .

Инфраструктура авторизации OAuth 2.0 позволяет стороннему приложению получать ограниченный доступ к службе HTTP, либо от имени владельца ресурса, организуя взаимодействие утверждения между владельцем ресурса и службой HTTP, либо позволяя стороннему приложению получить доступ от своего имени. — https://tools.ietf.org/html/rfc6749

OpenID Connect 1.0 — это простой идентификационный уровень поверх протокола OAuth 2.0 . Это позволяет клиентам проверять подлинность конечного пользователя на основе аутентификации, выполняемой сервером авторизации, а также получать базовую информацию о профиле конечного пользователя взаимодействующим и REST-подобным способом — https: // openid. сеть / подключение /

Эти два стандарта тесно связаны со спецификацией JSON Web Token ( JWT ), которая часто используется в качестве токена-носителя OAuth 2.0 .

JSON Web Token (JWT) — это компактное, безопасное для URL средство представления заявок, передаваемых между двумя сторонами. — https://tools.ietf.org/html/rfc7519

На фоне многочисленных утечек данных и утечек личной информации (привет, Мариотт ) безопасность становится как никогда важной. Абсолютно необходимо ознакомиться с лучшими практиками и рекомендациями по безопасности, следовать им и быть в курсе последних новостей. Два превосходных руководства по этому вопросу, « Наилучшие текущие практики безопасности OAuth 2.0» и «Наилучшие текущие практики веб-токенов JSON» , безусловно, относятся к категории, которую необходимо прочитать.

5. Поставщики удостоверений

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

Для платформы JCG Car Rentals мы собираемся использовать Keycloak , признанное решение с открытым исходным кодом для управления идентификацией и доступом, которое полностью поддерживает OpenID Connect .

Keycloak — это решение для управления идентификацией и доступом с открытым исходным кодом, предназначенное для современных приложений и сервисов. Это позволяет легко защищать приложения и сервисы практически без кода. — https://www.keycloak.org/about.htmlЕщ

Keycloak поставляется с достаточно подробными руководствами по настройке и установке, но стоит упомянуть, что мы собираемся использовать его для управления личностью клиентов JCG Car Rentals и обслуживающего персонала.

Помимо Keycloak , еще одной известной альтернативой с открытым исходным кодом является WSO2 Identity Server , который также мог бы работать для JCG Car Rentals .

WSO2 Identity Server — это расширяемое IAM-решение с открытым исходным кодом, позволяющее объединять и управлять удостоверениями как в корпоративных, так и в облачных средах, включая API, мобильные устройства и устройства Интернета вещей, независимо от стандартов, на которых они основаны. — https://wso2.com/identity-and-access-management/features/

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

6. Защита приложений

Безопасность на стороне приложений и сервисов, вероятно, будет сосредоточена на большинстве усилий. В экосистеме Java в основном существуют две базовые платформы для управления механизмами аутентификации и авторизации : Spring Security и Apache Shiro .

Spring Security — это мощная и настраиваемая среда аутентификации и контроля доступа. Это де-факто стандарт для защиты приложений на базе Spring. — https://spring.io/projects/spring-security

Действительно, поскольку наша служба бронирования построена на основе Spring Boot и Spring WebFlux , выбор в пользу Spring Security очевиден. Требуется буквально несколько строк конфигурации для полноценной интеграции OpenID Connect в сервис. Фрагмент кода ниже иллюстрирует только один из возможных способов сделать это.

@EnableReactiveMethodSecurity
@EnableWebFluxSecurity
@Configuration
public class WebSecurityConfiguration {
    @Value("${spring.security.oauth2.resourceserver.jwt.issuer-uri}")
    private String issuerUri;
 
    @Bean
    SecurityWebFilterChain securityWebFilterChain(ServerHttpSecurity http){
        http
            .cors()
            .configurationSource(corsConfigurationSource())
            .and()
            .authorizeExchange()
            .pathMatchers(HttpMethod.OPTIONS).permitAll()
            .anyExchange()
            .authenticated()
            .and()
            .oauth2ResourceServer()
            .jwt();
        return http.build();
    }
 
    @Bean
    ReactiveJwtDecoder jwtDecoder() {
        return ReactiveJwtDecoders.fromOidcIssuerLocation(issuerUri);
    }
}

spring.security.oauth2.resourceserver.jwt.issuer-uri указывает на экземпляр JCG Car Rentals царства Keycloak . В случае, когда Spring Security выходит за рамки, Apache Shiro , безусловно, стоит рассмотреть.

Apache Shiro — это мощная и простая в использовании инфраструктура безопасности Java, которая выполняет аутентификацию, авторизацию, криптографию и управление сеансами… — https://shiro.apache.org/

Немного менее известен механизм безопасности pac4j, также ориентированный на защиту веб-приложений и веб-сервисов. Веб-портал администрирования платформы JCG Car Rentals использует pac4j для интеграции с Keycloak с использованием OpenID Connect .

Поскольку OpenID Connect использует JWT (и связанные спецификации), вам может понадобиться встроить одну из библиотек, которая реализует эти спецификации. Наиболее широко используемые из них включают Nimbus JOSE + JWT , jose4j , Java JWT и Apache CXF .

Если мы расширим наш охват за пределы только Java до более широкой среды JVM, есть несколько других библиотек, с которыми вы можете столкнуться. Одним из них является Silhouette , используемый в основном веб-приложениями Play Framework .

7. Хранение секретов в безопасности

Большинство (если не все) сервисов в типичной микросервисной архитектуре будут зависеть от какой-либо конфигурации, чтобы функционировать как задумано. Эта конфигурация обычно специфична для среды, в которой развернут сервис, и, если вы следуете методологии 12 Factor App , вы уже знаете, что такая конфигурация должна быть выведена из кода и отделена от нее.

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

К счастью, есть несколько вариантов. Самый простой — использовать шифрование и хранить только зашифрованные значения. Для приложений Spring Boot вы можете использовать Spring Boot CLI вместе с Spring Cloud CLI для шифрования и дешифрования значений свойств.

$ ./bin/spring encrypt --key <secret> <value><br>
d66bcc67c220c64b0b35559df9881a6dad8643ccdec9010806991d4250ecde60

Такие зашифрованные значения должны иметь префикс в конфигурации со специальным префиксом {cipher} , как в следующем фрагменте YAML :

spring:   
  data:     
    cassandra:       
      password:"{cipher}d66bcc67c220c64b0b35559df9881a6dad8643ccdec9010806991d4250ecde60"

Чтобы настроить симметричный ключ, нам просто нужно установить свойство encrypt.key или лучше, использовать переменную окружения ENCRYPT_KEY . Интеграция Jasypt Spring Boot работает аналогичным образом, обеспечивая поддержку шифрования для источников свойств в приложениях Spring Boot .

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

Vault защищает, хранит и строго контролирует доступ к токенам, паролям, сертификатам, ключам API и другим секретам в современных вычислениях. — https://learn.hashicorp.com/vault/#getting-started

Vault делает управление секретами безопасным и действительно простым. Сервисы, созданные на основе Spring Boot , такие как служба бронирования на платформе JCG Car Rentals , могут воспользоваться преимуществами первоклассной интеграции Spring Cloud Vault .

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-vault-config</artifactId>
</dependency>

Одной из самых мощных функций, которые предоставляет Spring Cloud Vault, является возможность подключить хранилище ключей / значений Vault в качестве источника свойств приложения. Служба бронирования использует это, используя конфигурационный файл bootstrap.yml .

spring:
  application:
    name: reservation-service
  cloud:
    vault:
      host: localhost
      port: 8200
      scheme: https
      authentication: TOKEN
      token: <token>
      kv:
        enabled: true

Хотя Vault , вероятно, является наиболее известным, существует ряд достойных альтернатив, которые хорошо вписываются в архитектуру микросервиса . Одним из пионеров является Keywhiz , система для управления и распространения секретов, которая была разработана и открыта компанией Square . Другой — Knox , сервис для хранения и ротации секретов, ключей и паролей, используемых другими сервисами, вышел из Pinterest .

8. Забота о ваших данных

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

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

9. Сканируйте свои зависимости

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

Проверка зависимостей OWASP — это решение с открытым исходным кодом, которое можно использовать для сканирования приложений Java с целью выявления использования известных уязвимых компонентов. Он имеет специальные плагины для Apache Maven , Gradle , SBT и интегрирован в определения сборок каждого сервиса JCG Car Rentals .

<plugin>
    <groupId>org.owasp</groupId>
    <artifactId>dependency-check-maven</artifactId>
    <version>4.0.0</version>
    <executions>
        <execution>
            <goals>
                <goal>check</goal>
            </goals>
        </execution>
    </executions>
</plugin>

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

зависимость	CPE	Координаты	Высшая степень тяжести	CVE Count	CPE Confidence	Количество доказательств
июль к SLF4J-1.7.25.jar	CPE: / а: SLF4J: SLF4J: 1.7.25	org.slf4j: июль к SLF4J: 1.7.25	Высокий	1	Самый высокий	28
JCL-над-SLF4J-1.7.25.jar	CPE: / а: SLF4J: SLF4J: 1.7.25	org.slf4j: JCL-над-SLF4J: 1.7.25	Высокий	1	Самый высокий	29
SLF4J-апи-1.7.25.jar	CPE: / а: SLF4J: SLF4J: 1.7.25	org.slf4j: SLF4J-апи: 1.7.25	Высокий	1	Самый высокий	29

Поскольку в JCG Car Rentals есть несколько компонентов, использующих Node.js , важно также проверять зависимости пакетов для выявления уязвимостей. Недавно введенная команда npm audit сканирует каждый проект на наличие уязвимостей и автоматически устанавливает любые совместимые обновления для уязвимых зависимостей. Ниже приведен пример выполнения команды аудита .

$ npm audit
 
                       === npm audit security report ===
found 0 vulnerabilities
 in 20104 scanned packages

10. Упаковка

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

Clair — это проект с открытым исходным кодом для статического анализа уязвимостей в контейнерах приложений (в настоящее время включает appc и Docker ). — https://github.com/coreos/clair

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

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

gVisor — это ядро пользовательского пространства, написанное на Go, которое реализует значительную часть поверхности системы Linux. Он включает среду выполнения Open Container Initiative (OCI), называемую runsc которая обеспечивает границу изоляции между приложением и ядром хоста. — https://github.com/google/gvisor

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

11. Следите за своими журналами

Удивительно, как часто журналы приложений или сервисов становятся дырой в безопасности, пропуская конфиденциальную или личную информацию ( PII ). Обычные подходы к решению таких проблем — использование маскировки, фильтрации, очистки и анонимизации данных .

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

12. Оркестровка

До сих пор мы были в основном сосредоточены на том, как сделать меры безопасности неотъемлемой частью приложений и сервисов, используя выделенные библиотеки и платформы. Это все хорошо, но со временем вы можете увидеть, как одни и те же шаблоны появляются снова и снова. Разве не было бы замечательно, если бы мы могли снять такие повторяющиеся сквозные проблемы где-то еще? Это имеет смысл, и в некоторой степени это уже происходит …

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

На данный момент наиболее продвинутые, готовые к работе сервисные сетки включают Istio , Linkerd и Consul Service Mesh . Хотя мы поговорим об этих вещах позже в этом руководстве, стоит упомянуть, что они берут на себя множество проблем, следуя лучшим практикам и соглашениям в области безопасности.

13. Запечатанное Облако

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

Давайте кратко рассмотрим то, что лидеры в космосе имеют для вас. Microsoft Azure включает Key Vault для шифрования ключей и небольших секретов (например, паролей), но полный список услуг, связанных с безопасностью, является довольно полным. У этого также есть центр безопасности , универсальное обслуживание для унифицированного управления безопасностью и продвинутой защиты от угроз.

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

AWS , давний лидер в этой области, может выбирать из множества продуктов для обеспечения безопасности . Он даже предлагает две разные службы для управления ключами и секретами шифрования: Служба управления ключами ( KMS ) и Менеджер секретов . Помимо управляемого предложения, Стоит упомянуть открытый Confidant от Lyft с открытым исходным кодом, который хранит секреты в DynamoDB, используя шифрование в состоянии покоя. Эта ссылка на веб-страницу облачной безопасности поможет вам начать работу.

14. Выводы

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

15. Что дальше

В следующем разделе руководства мы поговорим о различных методах и методах тестирования в контексте микросервисной архитектуры .