Як насправді побудувати безпечну та надійну хмарну архітектуру AWS, не втрачаючи розуму

Вступ

Якщо ви коли-небудь намагалися спроектувати хмарну архітектуру в AWS з нуля, ви, мабуть, вже знаєте: це в рівній мірі свобода і хаос. Існує тисяча способів побудувати щось, і стільки ж способів все зіпсувати.

Короткий погляд на документацію AWS може наштовхнути вас на думку: "Круто, ми просто спостерігатимемо за першокласними практиками". Але в реальному міжнародному середовищі першокласні практики не часто відповідають потребам реального комерційного підприємства, обмеженням цінового діапазону або людським помилкам. Ось чому співпраця з такими професіоналами, як perfsys, на ранніх етапах може запобігти азартній грі з дірками в захисті та ускладненням при масштабуванні пізніше.

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

Почнемо з очевидного: AWS - це звір

За допомогою AWS можна створити практично все, що завгодно. Від стартапів для двох людей до розлогих корпоративних платформ, всі будівельні блоки є тут - EC2, Lambda, RDS, S3, IAM, VPC, і цей список можна продовжувати. У чому підступ? Чим більше варіантів у вас є, тим легше створити заплутаний безлад.

Справа не в тому, що AWS погано спроектований. Просто ви повинні спроектувати його правильно. Інакше ви отримаєте те, що деякі команди називають "хмарними спагеті": взаємозалежні сервіси, жорстко закодовані секрети, відсутність тегів, відсутність логування, і абсолютно не зрозуміло, що і скільки коштує.

Надійність і безпека - це не просто приємні дрібнички

Спокусливо вважати безпеку та надійність проблемою майбутнього. "Ми захистимо його після запуску". "Ми додамо моніторинг на наступному спринті". Але запитайте будь-кого, хто мав справу з витоком даних або багатогодинним відключенням - пропускаючи ці кроки, ви в кінцевому підсумку будете працювати всю ніч.

Що насправді означає надійність

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

Чи є у вас надмірність у всіх зонах доступності? Чи може ваша система витримати відмову вузла бази даних без втрати даних або помилок? Чи запускаєте ви критичні робочі навантаження в одному регіоні, тому що "так було найпростіше розгорнути"? Це питання, які відокремлюють робочі системи від відмовостійких.

А безпека? Це не тільки IAM

Так, управління ідентифікацією та доступом (IAM) - це перша стіна. Але безпека виходить далеко за її межі. Загальнодоступні відра S3. Ролі з надмірними повноваженнями. Секрети, закодовані в лямбда-функціях. Логування вимкнене "для економії коштів". Все це бомби уповільненої дії.

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

Будівельні блоки, які насправді мають значення

Гаразд, давайте перейдемо до суті. Ось що важливо, коли ви будуєте безпечну, надійну архітектуру на AWS - і де команди найчастіше помиляються.

Правильне використання ролей IAM (так, дійсно)

Ролі IAM дуже потужні. Іноді навіть занадто потужні. Занадто легко натиснути на "AdministratorAccess", тому що щось не працює, пообіцяти виправити це пізніше... а потім так і не виправити.

Ви повинні заблокувати це на ранній стадії. Принцип найменших привілеїв - це не просто найкраща практика, це єдиний розумний спосіб працювати. Це означає:

• Розмежування ролей для кожної служби

• Уникайте підстановочних знаків у дозволах

• Короткострокові облікові дані

• Обов'язкове MFA для користувачів-людей

Звучить боляче? Так і є. Але так само, як і пояснення вашому начальнику, чому хтось викрав дані клієнтів через неправильно налаштовану лямбду.

Відокремлюйте свою мережу так, як ви це маєте на увазі

Це ще одна сфера, де ярлики дають зворотний ефект. Вам не потрібне надскладне налаштування мережі, але деякі основи мають велике значення:

• Публічні підмережі лише для речей, які мають виходити в інтернет (наприклад, ALB)

• Приватні підмережі для всього іншого

• NAT-шлюзи для контрольованого вихідного доступу

• Кінцеві точки VPC для службового трафіку AWS без виходу в публічний інтернет

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

Ведення журналів і моніторинг: Ви не можете виправити те, чого не бачите

Це навіть не повинно більше обговорюватися. Ведення журналів не є необов'язковим. Якщо ви не реєструєте показники CloudTrail, CloudWatch та журнали потоків VPC, ви літаєте наосліп.

Але ось у чому заковика - одного лише ведення журналів недостатньо. Вам потрібно фактично дивитися на журнали. Створюйте оповіщення для того, що важливо. Відфільтрувати шум. І переконайтеся, що журнали централізовані для всіх акаунтів і регіонів. Фрагментарна видимість - це не видимість.

Шифруйте все (без винятків)

Використовуйте KMS для даних у стані спокою. Використовуйте TLS для даних, що передаються. Ротація ключів. Контролюйте доступ. Це одна з тих сфер, де лінощі зараз коштують дуже дорого пізніше.

І не забувайте про такі речі, як шифрування RDS, налаштування гучності EBS та застосування TLS на шлюзі API. Ці маленькі деталі складаються в одне ціле.

Інфраструктура як код або крах

Все ще розгортаєте за допомогою консолі AWS? Це добре для розробників, але небезпечно для користувачів.

Використовуйте Terraform, CloudFormation або CDK. Що б не віддавала перевагу ваша команда - просто оберіть щось одне і дотримуйтесь цього. Контролюйте версії своїх шаблонів. Використовуйте CI/CD для розгортання. Автоматизуйте відкати. Ручне розгортання - це відкрите запрошення для помилок.

Також: позначайте все тегами. Ресурси без тегів схожі на кабелі без етикеток - ніхто не знає, для чого вони призначені, і всі бояться їх чіпати.

Масштабування без занепаду

Давайте прояснимо: AWS любить, коли ви надаєте більше ресурсів. Ви отримуєте "продуктивність", вони отримують ваші гроші. Ефективне масштабування - це знання ваших шаблонів і планування відповідно до них.

Використовуйте групи автоматичного масштабування, точкові екземпляри (обережно) і шари кешування. Але найголовніше: тестуйте під навантаженням. Останнє, чого ви хочете, це виявити, що ваш екземпляр RDS розплавився під реальним трафіком через два дні після запуску.

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

Плани аварійного відновлення не є необов'язковими

Що станеться, якщо регіон вийде з ладу? Що, якщо ваша основна база даних буде пошкоджена? Якщо відповідь "е-е... у нас будуть проблеми", то настав час переглянути вашу стратегію аварійного відновлення.

Це не означає створення ідентичної копії вашої інфраструктури в іншому регіоні. Це означає знати:

• Що б ви відновили

• Скільки часу це займе

• Які дані будуть втрачені (якщо такі є)

• Хто за що відповідає під час обходу відмови

І так, ви повинні протестувати свій план відновлення. Інакше це просто вигадка.

Поширені антипаттерни, яких слід уникати

Давайте побіжно розглянемо деякі "ні-ні", які з'являються занадто часто:

• Один великий обліковий запис для всього: використовуйте AWS Organizations. Окремо prod, dev, staging і т.д.

• Залишати дефолтні VPC та групи безпеки недоторканими: заблокуйте їх.

• Надмірно покладатися на екземпляри t2.micro "для тестування" - зрештою вони опиняться в продакшені.

• Відсутність витрат на CloudWatch в бюджеті: так, ведення логів коштує грошей. Відсутність реєстрації коштує більше.

• Надання доступу для "швидкого виправлення": замість цього виправте свій процес.

Заключні слова? Залишайтеся гнучкими, залишайтеся розсудливими

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

Ви ніколи не будете повністю "готові" - і це нормально. Важливо бути цілеспрямованим. Ставити складні питання на ранніх стадіях. Часто проводити аудит. Автоматизувати там, де це важливо. І знати, коли звернутися за допомогою.

Тому що давайте будемо чесними - AWS потужна, але в ній також легко загубитися. Робота з досвідченими інженерами, які живуть і дихають хмарною архітектурою, може зробити різницю між "це працює, в основному" і "ми спимо вночі".

І заради цього варто будувати.