Лекция 116: Безопасность метрик: ограничение доступа к Actuator

Зачем защищать метрики?

Итак, представьте... Вы с гордостью настроили Actuator в своём учебном (или реальном) проекте и наконец-то можете видеть /metrics, /health и другие эндпоинты в действии. Вы чувствуете себя гением мониторинга, но внезапно обнаруживаете, что... любой желающий также может получить доступ к этим данным. Сюрприз!

Actuator даёт доступ к весьма чувствительной информации о вашем приложении: состояние здоровья, загрузка CPU, использование памяти, количество потоков и множество других данных. Теперь представьте, что злоумышленник использует эти данные для атаки на ваше приложение. Угрожающе!

Потенциальные угрозы

1. Утечка информации о системе: метрики могут показывать критическую информацию, например, устаревшую версию JVM или зависимости, которые могут содержать уязвимости.
2. Разведка перед атакой: данные о состоянии системы могут быть использованы для выбора подходящего времени для атаки.
3. Перегрузка системы: злоумышленник может отправлять множество запросов к Actuator эндпоинтам, что повлечёт за собой дополнительную нагрузку.

Итог: ограничение доступа к Actuator эндпоинтам — это не просто рекомендация, а абсолютная необходимость. Давайте разберёмся, как это правильно делать.

Настройка безопасности для Actuator

По умолчанию Spring Boot Actuator предоставляет эндпоинты, которые могут быть открыты для всех (в зависимости от уровня конфигурации). Давайте защитим их, используя Spring Security.

1. Подключение зависимости Spring Security

Если в вашем проекте ещё нет Spring Security, добавьте его. Для Maven это будет выглядеть так:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-security</artifactId>
</dependency>

Для Gradle:

implementation 'org.springframework.boot:spring-boot-starter-security'

2. Включение базовой безопасности

Как только Spring Security подключен, доступ к большинству Actuator эндпоинтов по умолчанию будет закрыт. Теперь для доступа потребуется аутентификация.

Попробуйте зайти на любой Actuator эндпоинт, например, /actuator/health. Вы обнаружите, что теперь браузер требует ввести логин и пароль. Поздравляю, первый уровень безопасности настроен!

Spring Security автоматически создаст пользователя с логином user и паролем, который будет сгенерирован при старте приложения. Этот пароль можно увидеть в логах:

Using generated security password: 2a9c2b52-4f3d-4937-b5d0-8b0fe9ed8702

3. Изменение учетных данных

Использовать сгенерированный пароль можно лишь временно. Давайте настроим более понятные учетные данные в файле application.properties:

spring.security.user.name=admin
spring.security.user.password=supersecurepassword

Теперь вы сможете логиниться с заданными логином и паролем.

4. Гранулярное управление доступом

Что, если вы хотите, чтобы различные метрики были доступны только определённым ролям? Например, эндпоинт /actuator/health может быть общедоступным, а вот /actuator/metrics — только администратору.

Конфигурация доступа через HttpSecurity

Для этого необходимо настроить SecurityFilterChain:

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;
import org.springframework.security.web.SecurityFilterChain;

@Configuration
public class SecurityConfig {

    @Bean
    public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
        http
            .authorizeHttpRequests()
                .requestMatchers("/actuator/health").permitAll() // Открытый доступ к /health
                .requestMatchers("/actuator/**").hasRole("ADMIN") // Доступ к остальным только для администратора
                .and()
            .httpBasic(); // Используем базовую аутентификацию
        return http.build();
    }
}

Настройка ролей пользователей

При использовании Spring Security с ролями, необходимо настроить пользователей с их ролями. Например:

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.security.core.userdetails.User;
import org.springframework.security.core.userdetails.UserDetailsService;
import org.springframework.security.provisioning.InMemoryUserDetailsManager;

@Configuration
public class MyUserDetailsService {

    @Bean
    public UserDetailsService userDetailsService() {
        var user1 = User.withDefaultPasswordEncoder()
                        .username("user")
                        .password("password")
                        .roles("USER")
                        .build();

        var admin = User.withDefaultPasswordEncoder()
                        .username("admin")
                        .password("adminpassword")
                        .roles("ADMIN")
                        .build();

        return new InMemoryUserDetailsManager(user1, admin);
    }
}

Теперь пользователь admin будет иметь доступ к Actuator эндпоинтам, а пользователь user — нет.

Настройка через application.properties

Если вы не хотите писать код, Spring Boot позволяет упростить конфигурацию безопасности через application.properties:

management.endpoints.web.exposure.include=health,info,metrics
management.endpoint.health.probes.enabled=true

# Защита всех эндпоинтов
spring.security.user.name=admin
spring.security.user.password=supersecurepassword

Типичные ошибки при настройке безопасности

Несоответствие ролей

Если вы создадите пользователя без соответствующей роли (ROLE_ADMIN для Actuator), он не сможет получить доступ, даже если логин и пароль введены верно. Убедитесь, что роли чётко настроены как в коде, так и в данных.

Полное отключение безопасности

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

Когда и какие эндпоинты открывать?

Иногда может быть полезно оставить часть метрик открытыми. Например, эндпоинт /health может быть открыт для систем мониторинга, таких как Kubernetes, чтобы следить за состоянием приложения.

Но всегда ограничивайте доступ к более подробным эндпоинтам, таким как /metrics или /env, только для администраторов.

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