⁠#single_account vs #multi_account_strategy

Споры о преимуществах той или иной стратегии ("всё/все в одном" или #мультиаккаунт) бессмысленны. Не буду хохмить про то, что они очень часто ведутся между теми, кто уже давно ест апельсины и теми, кто никогда их не пробовал, но не одобряет. Если максимально коротко - у каждого способа есть набор очевидных и неочевидных плюсов и минусов, однако #multi_account_strategy — суть современный способ работы современного проекта, а потому ориентироваться нужно именно на него.

Объять столь большую и радикально отличающуюся тему быстро невозможно, потому буду разбирать поэтапно, усложняя и объясняя по ходу.

===
Минимальная схема
===

Это классическая и общепринятая пару лет назад схема разделения — простая и понятная, с неё удобно начинать (как и я когда-то), условно для небольшой команды с одним проектом и одним девопсом.

По принципу разбиения схему можно назвать "мухи и котлеты". Всё, что не относится к поднимаемым окружениям - это условный Devops аккаунт. Окружения dev-stg-prod (test, etc) поднимаются единым образом, т.е. условно из одного шаблона и лишь с разными настройками.

Окружения живут в своих VPC и соединяются с Management VPC с помощью VPC peering. Доступ к закрытым ресурсам (без внешних айпишников) происходит через промежуточный Bastion инстанс.

Всё необходимое для поднятия окружений, различные ресурсы и настройки - всё лежит в Devops аккаунте, куда может иметь доступ лишь девопс, а разработчики ходят в dev-окружение и им выделяется доступ (временно, для деплоя) в stage-prod-etc.

Это (относительно) просто в реализации и поддержке, схема удовлетворяет требованиям различных #compliance (например, #NIST) и наверняка подойдёт для многих проектов, особенно тех, кто хочет начать использовать мультиаккаунты.

⁠Дальнейшее усложнение AWS #Organizations происходит по мере увеличения количества проектов, команд, требований и т.д.

===
Расширенная схема
===

• Общие ресурсы (ECR, снэпшоты, AMI и др.) вместе с #Shared_VPC выделяются в Shared аккаунт.

• Централизованный мониторинг и логи (ELK/Prometheus/Grafana/Sentry и т.д.) занимают свой аккаунт Monitoring (логи прода могут отправляться туда же или в отдельные - тут чисто условно).

• Бэкапы переезжают в DR (Disaster Recovery) аккаунты своих проектов.

• Наборы окружений dev-test-stg-prod-dr объединяются в #OU (Organization Units) для возможности применения к ним групповых SCP политик (объединение может быть и как Dev OU, DR OU etc - тоже чисто условно).

• Если ваша контора хочет целиком переехать в AWS, то выделяется отдельный аккаунт Organization для "организационных" вещей (название не самое удачное, речь об организации-фирме-компании, где, видимо, вы работаете :) ) — AD (Active Directory) для юзеров (самих работников), используемые для #SSO как единой точки входа, а также финансы, биллинги и прочие бухгалтерии, которые совсем не про код - всё будет там.

Процесс детализации #multi_account_strategy можно продолжать дальше - например, добавить OU для #HIPAA и прочих #compliance, где посредством #SCP будут отрабатывать их требования. Многие используеют Sandbox и/или личные аккаунты для разработчиков. И так далее и тому подобное — основные типы уже были перечислены и это уже лишь детали.

Если у вас годами себе мирно жили тучи файлов на #s3 и вдруг выясняется, что по #compliance причинам теперь их всех нужно зашифровать либо по требованиями аудита требуется всем проставить (переставить) тэги или ещё какая-то глобально-массовая напасть — для всех таких работ теперь есть нативный инструмент #s3_batch_operations:

https://aws.amazon.com/blogs/aws/new-amazon-s3-batch-operations/

Мало кто задумывается, что не все сервисы Амазона имеют #SLA. В частности, его нет у #CloudFormation, так что все ваши претензии, что он "тупит", "тормозит", "зачтомыбабкиплатим" и "вытамсовсемохренели" - можно смело слать в девнулл.

Полный список AWS сервисов с SLA можно глянуть по ссылке:

https://aws.amazon.com/legal/service-level-agreements/

Однако в ходе решения каких-то вопросов (например, по теме #compliance) может потребоваться более детальная информация.

Допустим, у вас активно используется #CloudTrail и #Config и требуется знать, какие сервисы он покрывает (или наоборот). Или ваш проект секретно секретный и нужно максимально использовать те сервисы, что имеют at-rest-encryption.

Для этого вам поможет следующая ссылка:

https://summitroute.github.io/aws_research/service_support.html

#info

⁠Сертификаты-требования-стандарты — Compliance

Когда вам вдруг потребовалось разобраться с вашим приложением на Амазоне и его соответствия каким-то сертификатам/требованиям/стандартам (в русском языке нет простого и точного соответствия, потому лучше использовать #compliance), то прежде, чем гуглить и википедить, стоит пройти по официальной ссылочке:

https://aws.amazon.com/compliance/programs/

К примеру, если заказчик вдруг поинтересовался, сможет ли он выйти с вашим приложением на американский рынок медицинских услуг, а вам нужно хоть что-то быстро ответить — берите HIPAA и смотрите, какие из используемых вами AWS сервисов, на которых строится ваше приложение, сертифицировано #HIPAA (список сервисов пополняется):

https://aws.amazon.com/compliance/hipaa-eligible-services-reference/

Наличие в этом списке ничего не гарантирует, однако вы хотя бы сможете сформулировать "может соответствовать".

Также там имеются и другие полезные документы. В любом случае, даже если вы не найдёте нужного (или не разберётесь - нужное оно или нет), то это отличное место надёргать грозных картинок для вашей презентации.

#аудит_своими_руками

DNSSEC на AWS:

https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-configuring-dnssec.html

Для KSK ключа используется ассиметричный KMS-CMK.

Много лет востребованная фича, теперь уже и большинство зон подписано:

http://stats.research.icann.org/dns/tld_report/

#Route53 #compliance

Использование AWS Config + SSM для автоматизации закрытия открытых портов (например, для соблюдения compliance требований):

https://aws.amazon.com/blogs/security/how-to-auto-remediate-internet-accessible-ports-with-aws-config-and-aws-system-manager/

#Config #SSM #security #compliance

​​aws-allowlister — полный набор SCP политик под различные compliance:

https://github.com/salesforce/aws-allowlister

С помощью данной утилиты можно создать SCP правила, которые разрешат работу лишь с сервисами, поддерживаемыми конкретным compliance, например, получить простыню (Allow List), где перечислены все AWS сервисы, разрешённые с точки зрения HIPAA.

Таким образом можно навесить полученный SCP на какой-то AWS аккаунт (или OU) и протестировать в нём окружение, что даст гарантию его HIPAA совместимости.

#SCP #compliance #security

​​Секретные регионы AWS

Слово "секретные" подразумевает не то, что они скрываются, а то, что это особо защищённые сегменты AWS облака. В этом легко убедиться, т.к. секретные регионы имеют свой раздел на сайте AWS:

https://aws.amazon.com/federal/us-intelligence-community/

Это физически другая инфраструктура с особым уровнем доступа - специальные каналы доступа к вычислительным мощностям AWS без доступа в глобальный интернет. Министерству Обороны США и спецслужбам тоже нужны мощности для своей работы, потому они взаимодействуют с AWS для выполнения всех своих специфических требований, оставляя при этом выгоды облака.

В 2014-м году появился AWS Top Secret регион, который используют разведывательные службы с уровенем Top Secret, а в 2017-м AWS Secret Region с уровнем Secret.

У секретных регионов максимальные требования по compliance CNSSI No.1253, которые дополняет требования NIST SP 800-53 (специальная версия от NIST 800-53, которая есть на AWS и на хабре).

У секретных регионов ограниченный набор сервисов (ещё меньше, чем для GovCloud), т.к. они должны пройти самую суровую сертификацию DoD SRG IL6. На текущий момент это "целых" 36 сервисов AWS:

https://aws.amazon.com/blogs/security/10-additional-aws-services-authorized-dod-impact-level-6-for-aws-secret-region/

Пишите в комментариях, если интересна эта сложноприменимая тема жёстких compliance и разделения сетей по уровням безопасности.

#security #compliance #AWS_Regions

​​📓 Лучшее сравнение "NIST CSF vs ISO 27001/2 vs NIST 800-53 vs SCF", что видел. Отлично подойдёт для тех, кто хочет глубоко разобраться в теме.

https://www.complianceforge.com/faq/nist-800-53-vs-iso-27002-vs-nist-csf-vs-scf

Главное на картинке в заголовке сверху:

1️⃣ Cамый всеобъемлющий стандарт Secure Controls Framework (SCF). Если вы параноик и хотите потратить весь свой бюджет на кибербезопасность, тогда смело делайте всё по этому стандарту.

2️⃣ NIST 800-53 есть его подмножество SCF. Если вам потребуется работать с военными или государственными структурами США, тогда сразу ориентируйтесь на NIST 800-53.

3️⃣ ISO 27001/2 есть его подмножество NIST 800-53. В статье кратко и доступно описана путаница 27001 vs 27002 — почему два стандарта. Расписано, почему многие бизнесы любят его использовать — он не настолько суров, а при этом очень популярен, особенно в крупных компаниях.

4️⃣ NIST CSF — самый простой, этим и хорош. Потому рекомендуется с него начинать небольшим компаниям.

Таблица внизу показывает ландшафт различных compliance с координатами по охвату и популярности типа квадрантов Gartner. При некоторой спорности, помогает сориентироваться и выстроить своё понимание, как соотносятся между собой PCI-DSS, HIPAA, FedRAMP, а также другие популярные и не очень стандарты.

Отдельно добавлю, что в AWS есть сервис Security Hub, который следит за всеми требованиями согласно этих стандартов применимо к AWS сервисам. И недавно появилась поддержка версии NIST 800-53 v.5:

https://docs.aws.amazon.com/securityhub/latest/userguide/nist-standard.html

А до этого у Security Hub появилась фича "Consolidated Control Findings" и теперь все проблемы можно увидеть сразу в одном месте:

https://docs.aws.amazon.com/securityhub/latest/userguide/controls-findings-create-update.html#consolidated-control-findings

Реально удобно, AWS Security Hub — must-have для безопасности! 👍

#security #compliance #SecurityHub

Интересный рассказ от @pyToshka про open source DevSecOps инструмент Wazuh:

https://www.youtube.com/watch?v=hSXpUj_RkEI

#devsecops #security #compliance #opensource