Не повторюй ці факапи при роботі з AWS. 1 частина
AWS — це як швейцарський ніж: у ньому є все і навіть більше. Саме за цією різноманітністю криється виклик. Без розуміння принципів і практик навіть профі можуть ненароком створити собі (і компанії) зайвий головний біль.
Тому про ризикові моменти варто знати заздалегідь. Ми зібрали типові помилки, які найчастіше трапляються під час роботи з AWS.
Матеріалу виявилося настільки багато, що одну статтю довелось розділити на кілька частин. У цій — розбираємо фейли з безпекою, управлінням витрат та порушенням вимог.
Помилки у безпеці
1. Вимкнена багатофакторна автентифікація (MFA) для root і IAM-користувачів
Root-акаунт має повний доступ до всіх ресурсів у хмарі. Без MFA будь-хто, хто отримає логін і пароль, може повністю знищити або викрасти дані компанії.
Як правильно: обов’язково вмикай MFA для root і всіх користувачів IAM, особливо з адміністративними правами. Найпростіший спосіб — через AWS Management Console з застосунком Authenticator.
2. Використання стандартних ключів та облікових даних AWS у репозиторіях коду
Розробники часто випадково комітять свої access keys або secret keys у GitHub. Навіть приватні репозиторії не гарантують безпеки, бо історію змін можна відновити.
Як правильно: замість ключів у коді використовуй змінні середовища або AWS Secrets Manager. Додатково — під’єднай автоматичне сканування секретів у CI/CD.
3. Надмірні дозволи для ролей IAM
Ролі з політиками типу *:* — класика усіх помилок. Користувач або застосунок отримує права на все, включно з видаленням баз даних чи створенням нових користувачів.
Як правильно: дотримуйся принципу найменших привілеїв (Least Privilege). Створюй окремі ролі з мінімально необхідними дозволами для кожного сервісу чи застосунку.
4. Відкриті групи безпеки
Інколи групи безпеки налаштовують так, що порти відкриті для всього світу (0.0.0.0/0). Це відкриває шлях для зовнішніх атак і сканування.
Як правильно: обмежуй доступ конкретними IP-адресами або внутрішніми VPC. Регулярно переглядай правила груп безпеки через AWS Config.
5. Відсутнє шифрування даних
Дані без шифрування — запрошення для зловмисників. У випадку витоку чи компрометації сховища зловмисник отримає їх у чистому вигляді.
Як правильно: активуй шифрування для всіх сервісів — від S3 і RDS до EBS. Для передачі даних використовуй HTTPS або TLS-з’єднання.
6. Конфіденційна інформація у звичайному тексті
Паролі, токени або ключі, збережені просто у файлах на EC2 як бомба сповільненої дії.
Як правильно: зберігай усе чутливе у Secrets Manager або Parameter Store. Якщо потрібно використовувати у скриптах — діставай через API з контрольованим доступом.
7. Відсутня ротація ключів IAM
Без регулярної ротації ключів ризик компрометації зростає. Один витік — і зловмисник має доступ назавжди.
Як правильно: налаштуй політику автоматичної ротації ключів або роби це вручну кожні 90 днів. AWS підтримує кілька активних ключів, щоб оновлення проходило без простою.
8. Загальнодоступні корзини S3
Найвідоміша помилка, через яку у відкритий доступ потрапляють гігабайти даних компаній.
Як правильно: вимкни публічний доступ на рівні акаунта. Використовуй політики S3 Bucket Policy лише для чітко визначених користувачів чи ролей.
9. Відсутність логів CloudTrail і VPC Flow Logs
Без логів неможливо відстежити, хто, коли й що робив у системі. А це критично при розслідуванні інцидентів безпеки.
Як правильно: активуй CloudTrail для всіх регіонів і зберігай логи у приватній S3 корзині. Для аналізу мережевого трафіку — VPC Flow Logs.
10. Відсутність регулярного сканування на вразливості
Навіть якщо все налаштовано правильно, нові вразливості з’являються щодня.
Як правильно: інтегруй автоматичні перевірки з AWS Inspector або сторонні сервіси типу Tenable чи Qualys. Проводь рев’ю безпеки щонайменше раз на квартал.
Помилки в управлінні витратами
1. Запуск великих екземплярів для невеликих робочих навантажень
Інженери часто вибирають EC2-екземпляри «із запасом» — на всяк випадок. У результаті — CPU використовується на 10%, а ти платиш за 100%.
Як правильно: регулярно аналізуй навантаження через CloudWatch і переходь на менші типи екземплярів або на auto scaling групи.
2. Невидалені неактивні екземпляри EC2, що продовжують споживати ресурси
Класика в DevOps-командах — «той тестовий інстанс, який ти створив на 5 хвилин, працює третій місяць поспіль».
Як правильно: налаштуй автоматичне завершення через Instance Scheduler або AWS Lambda, яка зупинятиме екземпляри без активності.
3. Використання екземплярів на вимогу для довгострокових завдань
Платити за on-demand інстанси постійно — як орендувати таксі на рік замість купити авто.
Як правильно: для стабільних і тривалих робочих навантажень переходь на Savings Plans або Reserved Instances. Це знижує витрати до 70%.
4. Неочищені еластичні IP-адреси
AWS стягує плату за EIP, якщо вони не прив’язані до активних інстансів. Часто такі адреси просто забувають після тестів або міграцій.
Як правильно: регулярно перевіряй невикористані IP у консолі EC2 та видаляй зайві.
5. Застарілі томи та знімки EBS
EBS — це зручно, але не безплатно. Старі знімки, створені для «резерву», можуть непомітно з’їдати бюджет.
Як правильно: впровадь політику життєвого циклу знімків (Snapshot Lifecycle Policy) та видаляй непотрібні вручну чи автоматично.
6. Неоптимальні витрати на передачу даних
Передача даних між регіонами або VPC може стати неприємним сюрпризом у рахунках. Особливо якщо архітектура побудована без урахування маршрутизації.
Як правильно: мінімізуй міжрегіональний трафік, використовуючи Edge Locations або CloudFront. Плануй мережеву топологію з урахуванням вартості.
7. Надмірне виділення ресурсів баз даних RDS
Інстанси баз даних часто обирають «із запасом» на майбутнє — і так залишають. У підсумку RDS працює напівпорожньою, але коштує дорого.
Як правильно: аналізуй використання CPU, пам’яті й IOPS через Performance Insights і переходь на менші типи інстансів або Aurora Serverless.
8. Відсутність аналізу витрат через AWS Cost Explorer
Без постійного моніторингу неможливо зрозуміти, куди «тікають» гроші.
Як правильно: користуйся Cost Explorer для щотижневого аналізу, встанови бюджети та попередження. А ще краще — інтегруй аналітику через Slack або пошту, щоб бачити зміни одразу.
Порушення вимог і корпоративного управління
1. Не вмикається AWS Config для перевірок відповідності
Без AWS Config ти буквально «літаєш наосліп». Цей сервіс відстежує зміни у конфігурації ресурсів і повідомляє, коли щось виходить за межі політик.
Як правильно: активуй AWS Config у кожному регіоні, створюй власні правила (наприклад, щоб EC2 завжди були в приватних підмережах) і автоматизуй виправлення невідповідностей.
2. Відсутність інструментів для виявлення загроз
GuardDuty, Security Hub, Inspector — це не додаткові фішки, а системи раннього попередження. Без них інциденти можуть залишитися непоміченими.
Як правильно: налаштуй GuardDuty для моніторингу підозрілої активності, використовуй AWS Security Hub для централізованого аналізу й регулярно перевіряй результати сканування Inspector.
3. Ігнорування регіональних вимог до зберігання даних
У деяких країнах закон вимагає, щоб дані користувачів зберігались лише на території цієї держави. Ігнорування цього може обернутися не просто помилкою, а юридичною проблемою.
Як правильно: вибирай регіони розгортання з урахуванням локальних вимог (наприклад, GDPR або ISO 27001), документуй, де зберігаються дані, і перевіряй це через AWS Config.
4. Відсутність політик контролю послуг (Service Control Policies, SCP)
Без SCP будь-який акаунт у межах організації може використовувати сервіси поза політикою компанії, наприклад створювати ресурси у заборонених регіонах або витрачати зайві кошти.
Як правильно: налаштуй SCP в AWS Organizations, щоб обмежити дії користувачів на рівні всієї структури — це захищає навіть від помилок адміністраторів.
5. Відсутність документального підтвердження власності на ресурси
Коли в організації сотні акаунтів, а ресурси створюють десятки інженерів, часто неможливо з’ясувати, хто відповідає за той чи інший ресурс.
Як правильно: використовуй теги типу Owner, Project, Environment. Це не лише спрощує аудит, а й допомагає при розподілі витрат.
6. Забуття архівування журналів для аудиту
Логи CloudTrail і VPC Flow Logs часто видаляються або перезаписуються без збереження копій. Це робить неможливим відстеження інцидентів заднім числом.
Як правильно: налаштуй архівування журналів у S3 з довгим періодом зберігання (до 7 років) і вкажи Glacier як рівень для архівних копій.
7. Відсутність стратегії тегування ресурсів
Без чіткої схеми тегів складно зрозуміти, хто створив ресурси, для чого вони потрібні, і чи їх можна видалити. У масштабі — це хаос.
Як правильно: запровадь політику тегування на рівні організації, автоматизуй її перевірку через AWS Config і контролюй відповідність.
8. Ігнорування моделі спільної відповідальності AWS
AWS відповідає за безпеку хмари, але не за безпеку твоїх даних у ній. Багато команд цього не розуміють — і залишають конфігурації відкритими.
Як правильно: ознайом команди з моделлю Shared Responsibility, розділи обов’язки й пропиши, хто відповідає за кожен рівень безпеки.
9. Відсутність оглядів за AWS Well-Architected Framework
Цей фреймворк допомагає оцінити стан інфраструктури за п’ятьма напрямами — від безпеки до фінансів. Але ним часто нехтують.
Як правильно: проводь регулярні Well-Architected Reviews для ключових проєктів і виправляй знайдені порушення. Це допомагає уникати ризиків до того, як вони стануть проблемою.
10. Відсутність навчання команд комплаєнсу
Команди можуть бути технічно сильними, але не розуміти вимог до зберігання, шифрування чи аудиту.
Як правильно: організуй внутрішні тренінги, сертифікації (наприклад, AWS Certified Security – Specialty) та регулярні воркшопи з комплаєнсу.
Післяслово
Фууух… Поки пальці наших копірайтерів перепочивають, радимо уважно пройтись по кожному з пунктів.
Якщо впізнав себе чи свою команду хоча б у кількох з них — час щось змінювати. Наприклад, оновити знання на курсі «AWS. Практикум з адміністрування» в ITEDU.
Навіть досвідченим фахівцям важливо іноді освіжати базу та тримати знання в тонусі.
Побачимось у 2 частині статті або на навчанні.