Що таке мікросервіси?

Це процеси для розробки програмних додатків, де додаток складається з інтегрованих сервісів. Кожен мікросервіс можна впровадити та запускати ним унікальний процес. Вони підключаються через чітко визначений механізм. Мікросервіс намагається вирішити одну проблему, як-от пошук даних, функція реєстрації або функція веб-сервіса. Отже, такий підхід певним чином підвищує гнучкість. Наприклад, це допомагає вільно оновлювати код однієї функції та перерозгортати решту архітектури мікросервісів.

Типова архітектура мікросервісів включає клієнтів, шлюз постачальників ідентифікаційних даних, формати обміну повідомленнями, базу даних, статичний вміст, керування та виявлення сервісів.

Для захисту мікросервісів застосовуються такі методи та інструменти:

• Більшість мікросервісів підтримують внутрішні API і не є видимими для зовнішніх агентів. Припустимо, хтось намагається зламати API (який є фреймворком, за допомогою якого розробники можуть взаємодіяти з веб-додатками). У цьому випадку вони можуть отримати лише обмежений доступ до HTTP.
• Межі домену захищені за допомогою автентифікації на основі ролей. Безпека починається від рівня бази даних до API програми з точними рольовими функціями, які визначають, хто має доступ, розгортання та масштабування.
• Забезпечення стандартного протоколу для контролю доступу до архітектури API, наприклад токенів, сертифікатів і мереж, використовуючи хмарні платформи з відкритим вихідним кодом, як-от Cloud Foundry і Kubernetes.
• Колись безпечний рівень сокетів (SSL) з новою версією TLS (безпека транспортного рівня) є криптогенними протоколами, які забезпечують безпеку зв'язку в комп'ютерних мережах. Ключі шлюзу API дозволяють розробникам програм отримати доступ до API. Аналогічно, білий список IP-адрес є ще однією функцією безпеки, яка дозволяє лише довіреному користувачеві отримати доступ або створити список надійних IP-адрес. Шлюзи API є широко використовуваним рішенням у безпеці мікросервісів.
• Регулярне сканування безпеки допомагає закрити витік. Крім того, при проектуванні разом із розробниками та архітекторами, потрібно з самого початку думати про безпеку. Єдиний вхід із шлюзом API та встановленими платформами безпеки є найкращим варіантом.
• Окрім безпеки додатків, не менш важлива безпека API. Тут ідентифікатор стає критичним, і необхідність інтеграції різних рівнів, таких як підключення та авторизація доступу, стає важливою.
• API керують архітектурою мікросервісів. Розробники використовують їх як контракти про те, що можуть робити мікросервіси, а що ні. Таким чином, центральним ІТ легше керувати мікросервісами, оскільки їх SLA (угода про рівень обслуговування) керується через шлюзи API. Оскільки шлюзи API діють як проксі для мікросервісів, вони забезпечують правильний баланс між управлінням ІТ та гнучкістю домену.
• Якщо хтось використовує мікросервіси, то SELinux (Linux з покращеною безпекою) є обов'язковою справою. Це архітектура безпеки для систем Linux, яка дозволяє адміністраторам краще контролювати всіх, хто має доступ до системи. Це також запобігає запуску програми в системі, що не є актуальним. Це звужує можливості зловмисника скомпрометувати контейнер і зробити його безпорадним. Знання того, як користуватися SELinux, є життєво важливим, оскільки будь-який контейнер робочого навантаження та залежний від нього контейнер потребують регулярних тестів та оновлень.
• Схема автентифікації SSO (єдиний вхід) дозволяє користувачеві входити в систему за допомогою єдиного ідентифікатора та пароля для кількох програм, пов’язаних із мікросервісами. При розробці проектів із кількома сервісами, як-от обслуговування даних і веб-додатків, таких як обслуговування HTML, багато розробників вважають мікросервіси хорошим варіантом і ідеальним підходом. Існує кілька підходів до впровадження SSO. Для доступу до всіх програм і різних сервісів можна пройти автентифікацію лише один раз. Існує два способи:

1. Додавання сервісу ідентифікації та програми гарантуватиме, що будь-який сервіс, яка має захищені ресурси, буде взаємодіяти из сервісом ідентифікації, щоб переконатися, що її облікові дані є дійсними. Якщо їх немає, він перенаправить користувача на автентифікацію.
2. Впровадженняи OpenID, щоб кожний сервіс обробляв свої власні ідентифікатори. Це означає, що користувачу необхідно авторизувати сервіс або програму окремо. Однак після цього це буде лише SSO.

Проблема в тому, що розробники так багато зосереджуються на модернізації додатків для бізнесу, і тому намагаються створити модель безпеки, яка відповідає існуючій системі. Це неправильний підхід, оскільки будь-яка поточна вразливість залишиться поза увагою. Іншим способом подвійного захисту або шифрування було б використання техніки JWT (веб-токен JSON) для єдиного входу між користувацькою програмою та іншою програмою.

• Інтеграція статичного тестування безпеки програми у вбудований процес працює краще для мікросервісів. Це покращить існуючий процес безпеки та водночас допоможе чітко виявити ризики після розгортання програми.
• Ефективність техніки безпеки залежить від середовища та інструментів, у яких розгорнутий мікросервіс. Інший спосіб – забезпечити повне шифрування диска, авторизацію та автоматизацію. Безпека ще більше посилюється, коли архітектура та шифрування забезпечують відповідність вимогам безпеки з точки зору аудиту. Процес документації, аудиту та сертифікації безпеки має гарантувати, що все заблоковано для PCI, ISO та інших вимог відповідності.

Висновок

Захист мікросервісів означає співпрацю з архітекторами, інженерами та службою інформаційної безпеки. Регулярні перевірки коду та статичний аналіз необхідні для звітів, які висвітлюють шаблони та докази, які передбачають атаки. Оскільки хтось керує мікросервісами з меншими командними обов’язками, підхід до постачання з ланцюгом поставок із належним контролем доступу на основі ролей також можливий.