AWS и ITSec Architecture
Препод на курсах ИБ архитектуры сегодня всех нервировал тем, что, будучи в прошлом разработчиком, он требовал делать не просто анализ взаимодействия между компонентами, но и подробно расписывать сами компоненты.
К примеру, есть задание на разработку системы распространения обновлений прошивки для автомобилей.
Система работает в AWS и использует такие амазоновские компоненты, как Code Commit, EKS и (no)SQL. Автомобили периодически подключаются к сервису через API с взаимной аутентификацией TLS, проверяют наличие обновлений и если найдут что-то новое, то загружают обновление и устанавливают его, отправляя в сервис отчёт о результатах.
Надо понять, какие наиболее вероятные векторы атак на такой сервис существуют.
И вот тут препод требует непременно расписать, используем ли мы, например, Docker, Kubernetes + OpenShift + Istio, flux, mesos или просто сервер приложений на VM.
При этом на разработку архитектуры даётся полчаса, а в требованиях к студентам курса не было знания технологий того же Амазона.
Вот я, например, по понятным причинам, хорошо знаю Azure, но это никакой пользы не несёт. Мои коллеги тоже не имеют большого dev-background и, как видно, приуныли.
Я спрашиваю, почему, например, не сосредоточиться на уязвимостях в "generic security controls".
Взять, к примеру, историю с кражей данных канадского банка Capital One, где причиной была некорректная конфигурация МЭ.
Или совсем свежая история с Imperva, где чуваки перенесли свою БД с конфиденциальной информацией, включая закрытые криптоключи, в AWS Relational Database Service, сделали снапшот для тестирования и разместили его на публично доступном compute instance, в результате чего вся AWS API key инфраструктура оказалась скомпрометирована до уровня админа.
Тут уже не надо быть гуру CI/CD pipelines, чтобы предложить возможные атаки. А если уж он так настаивает, чтобы мы лезли в гущи кубернетеса , то нужно давать гораздо больше, чем полчаса.
У того же амазона есть куча ресурсов по безопасности и комплайнсу https://aws.amazon.com/compliance/resources/ и даже бесплатные курсы https://aws.amazon.com/training/course-descriptions/security-fundamentals/, но их изучение отнимет никак не меньше пары дней.
Вдобавок, препод, как мне показалось, большой фанат AWS, потому что когда я ему рассказала про то, как утащили ключи у Imperva, он начал говорить, что это невозможно, потому что все виртуальные машины в AWS шифруются по умолчанию. Невозможно, но как-то утащили же? Впрочем, инцидент случился ещё в 2017 году. Возможно, тогда ещё не шифровали. Но для того, чтобы знать такие нюансы, нужно немного подучить матчасть. А так получается, что чувствуешь себя идиотом.
*Зря тот сабмиссв БСДМщик слился, когда я его приглашала у нас работать. Я думаю, он бы получил сегодня много удовольствия.
К примеру, есть задание на разработку системы распространения обновлений прошивки для автомобилей.
Система работает в AWS и использует такие амазоновские компоненты, как Code Commit, EKS и (no)SQL. Автомобили периодически подключаются к сервису через API с взаимной аутентификацией TLS, проверяют наличие обновлений и если найдут что-то новое, то загружают обновление и устанавливают его, отправляя в сервис отчёт о результатах.
Надо понять, какие наиболее вероятные векторы атак на такой сервис существуют.
И вот тут препод требует непременно расписать, используем ли мы, например, Docker, Kubernetes + OpenShift + Istio, flux, mesos или просто сервер приложений на VM.
При этом на разработку архитектуры даётся полчаса, а в требованиях к студентам курса не было знания технологий того же Амазона.
Вот я, например, по понятным причинам, хорошо знаю Azure, но это никакой пользы не несёт. Мои коллеги тоже не имеют большого dev-background и, как видно, приуныли.
Я спрашиваю, почему, например, не сосредоточиться на уязвимостях в "generic security controls".
Взять, к примеру, историю с кражей данных канадского банка Capital One, где причиной была некорректная конфигурация МЭ.
Или совсем свежая история с Imperva, где чуваки перенесли свою БД с конфиденциальной информацией, включая закрытые криптоключи, в AWS Relational Database Service, сделали снапшот для тестирования и разместили его на публично доступном compute instance, в результате чего вся AWS API key инфраструктура оказалась скомпрометирована до уровня админа.
Тут уже не надо быть гуру CI/CD pipelines, чтобы предложить возможные атаки. А если уж он так настаивает, чтобы мы лезли в гущи кубернетеса , то нужно давать гораздо больше, чем полчаса.
У того же амазона есть куча ресурсов по безопасности и комплайнсу https://aws.amazon.com/compliance/resources/ и даже бесплатные курсы https://aws.amazon.com/training/course-descriptions/security-fundamentals/, но их изучение отнимет никак не меньше пары дней.
Вдобавок, препод, как мне показалось, большой фанат AWS, потому что когда я ему рассказала про то, как утащили ключи у Imperva, он начал говорить, что это невозможно, потому что все виртуальные машины в AWS шифруются по умолчанию. Невозможно, но как-то утащили же? Впрочем, инцидент случился ещё в 2017 году. Возможно, тогда ещё не шифровали. Но для того, чтобы знать такие нюансы, нужно немного подучить матчасть. А так получается, что чувствуешь себя идиотом.
*Зря тот сабмиссв БСДМщик слился, когда я его приглашала у нас работать. Я думаю, он бы получил сегодня много удовольствия.