Лекція 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

# Захист усіх endpoints
spring.security.user.name=admin
spring.security.user.password=supersecurepassword

Типові помилки при налаштуванні безпеки

Невідповідність ролей

Якщо ти створиш користувача без відповідної ролі (ROLE_ADMIN для Actuator), він не зможе отримати доступ, навіть якщо логін і пароль введені правильно. Переконайся, що ролі чітко налаштовані як у коді, так і в даних.

Повне відключення безпеки

Деякі розробники для зручності просто відключають автентифікацію, роблячи Actuator доступним для всіх. Це може бути прийнятно тільки в локальній розробці, але ніколи — у продакшені. Завжди захищай метрики в реальних проєктах.

Коли й які ендпойнти відкривати?

Іноді корисно залишити частину метрик відкритими. Наприклад, ендпоінт /health можна відкрити для систем моніторингу, таких як Kubernetes, щоб стежити за станом аплікації.

Але завжди обмежуй доступ до більш детальних ендпоінтів, таких як /metrics чи /env, тільки для адміністраторів.

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