Я - великий прихильник безcерверних (serverless) технологій, і майже завжди надаю їм перевагу в порівнянні з більш традиційними методами. Cloud Run замість GKE, Fargate замість EKS, Pub/Sub замість Кафки та Aurora замість RDS. Це дешевше, цим легше управляти, менше інфраструктури... Але як щодо безпеки? Чи можливо насправді пересвідчитись, що ваші безсерверні процеси (та дані) захищені?
Міф 1: Та я просто запущу свій таск в хмарі, що може піти не так?
Зізнавайтесь, бували такі думки? В хмарі дуже легко експериментувати, особливо - коли будь-який код можна упакувати в контейнер та запустити в якомусь ECS чи Cloud Run.
Безсерверні технології - тобто, ті, в яких ми не маємо конкретної інфраструктури в традиційному сенсі - ще більше полегшують життя розробникам. Для будь-якого юз-кейса існує спеціалізований сервіс, тільки бери та використовуй. Давайте подивимось, чим загрожує ця легкість в використанні, з точки зору безпеки.
Одного грудневого ранку резиденти Австралійського штату Вікторія отримати електронний лист від свого уряду. Лист повідомляв їх про те, що після зламу місцевої компанії Optus вони отримають нові посвідчення водія…
В штаті Вікторія всього декілька мільйонів жителів, і цілий мільйон із них має отримати нові посвідчення водія, тому що найпопулярнішого оператора мобільного звʼязку - Optus - хакнули. Як це відбулося? Мабуть, якась серйозна хакерська група, можливо, спонсорована урядом недружньої країни, хакнула цю компанію Optus?
Виявляється, зовсім ні. Це була одна (1) людина, що знайшла відкритий API та завантажила дані всіх клієнтів. Просто endpoint в інтернеті.
Переписка між журналістом Джеремі Кьорком та хакером на форумі підтверджує, що ніякої автентифікації на цьому API не було. Просто зайшов, просто скачав дані десяти мільйонів австралійців.
Мабуть, хтось подумав, ну, я просто тестую API, воно ні до чого не приєднано, не потрібна автентифікація. А потім про цей API забули.
Ми не знаємо, яка технологія стояла за цим API компанії Optus в Австралії, але не важко уявити, що такі ситуації відбуваються, коли ми хочемо щось якнайшвидше запустити, використавши найлегшу можливу технологію. Цією технологією все частіше стають безсерверні продукти. Лямбда, Fargate, Cloud Run, Cloud Functions - все це дуже легко використовувати, але й дуже легко залишити відкритим.
Коли ми говоримо про традиційні системи і їх захист, зазвичай більшість уваги приділяється захисту мереж: відкриті порти, Security Groups, Firewall rules. Проте, у випадку безсерверних технологій, мережі у нас, як такової, немає. Складові захисту цих безсерверних технологій - інші.
- доступ до цього сервісу: хто може запустити цю функцію, хто може запустити цей контейнер, хто може активувати API.
- до чого має доступ сам сервіс: які дані може зчитувати та писати цей контейнер чи функція, куди пишуться логи, тощо.
- внутрішні механізми безпеки: вбудовані всередні коду.
Розгляньмо деталі налаштування цих доступів.