#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) и наверняка подойдёт для многих проектов, особенно тех, кто хочет начать использовать мультиаккаунты.
Споры о преимуществах той или иной стратегии ("всё/все в одном" или #мультиаккаунт) бессмысленны. Не буду хохмить про то, что они очень часто ведутся между теми, кто уже давно ест апельсины и теми, кто никогда их не пробовал, но не одобряет. Если максимально коротко - у каждого способа есть набор очевидных и неочевидных плюсов и минусов, однако #multi_account_strategy — суть современный способ работы современного проекта, а потому ориентироваться нужно именно на него.
Объять столь большую и радикально отличающуюся тему быстро невозможно, потому буду разбирать поэтапно, усложняя и объясняя по ходу.
===
Минимальная схема
===
Это классическая и общепринятая пару лет назад схема разделения — простая и понятная, с неё удобно начинать (как и я когда-то), условно для небольшой команды с одним проектом и одним девопсом.
По принципу разбиения схему можно назвать "мухи и котлеты". Всё, что не относится к поднимаемым окружениям - это условный Devops аккаунт. Окружения dev-stg-prod (test, etc) поднимаются единым образом, т.е. условно из одного шаблона и лишь с разными настройками.
Окружения живут в своих VPC и соединяются с Management VPC с помощью VPC peering. Доступ к закрытым ресурсам (без внешних айпишников) происходит через промежуточный Bastion инстанс.
Всё необходимое для поднятия окружений, различные ресурсы и настройки - всё лежит в Devops аккаунте, куда может иметь доступ лишь девопс, а разработчики ходят в dev-окружение и им выделяется доступ (временно, для деплоя) в stage-prod-etc.
Это (относительно) просто в реализации и поддержке, схема удовлетворяет требованиям различных #compliance (например, #NIST) и наверняка подойдёт для многих проектов, особенно тех, кто хочет начать использовать мультиаккаунты.
Ransomware Risk Management on AWS Using the NIST Cyber Security Framework (CSF)
https://d1.awsstatic.com/whitepapers/Security/ransomware-risk-management-on-aws-using-csf.pdf
Если попытаться отразить все аспекты безопасности из данного документа в сервисах AWS, то получится следующий (длинный) список.
🔹 Basic
Use antivirus software at all times.
▪️ Marketplace
Keep computers fully patched.
▪️ SSM Patch Manager
Block access to ransomware sites.
▪️ Route 53 Resolver DNS Firewall
▪️ Network Firewall
▪️ NACL
Allow only authorized apps.
▪️ SSM State Manager
Use standard user accounts
▪️ IAM
Make an incident recovery plan.
▪️ AWS Security Incident Response Guide
Backup and restore.
▪️ EBS Snapshots
▪️ Backup
▪️ CloudEndure Disaster Recovery
▪️ CodeCommit
Keep your contacts.
▪️ AWS Security Incident Response Guide
🔸 NIST Practice Guide goals
Backup
▪️ EBS Snapshots
▪️ Backup
▪️ CloudEndure Disaster Recovery
▪️ CodeCommit
Corruption testing
▪️ Config Rules
▪️ SSM State Manager
Denylisting
▪️ EC2 Security Groups
▪️ Route 53 Resolver DNS Firewall
▪️ Network Firewall
▪️ VPC endpoints
▪️ WAF
▪️ WAF Security Automations
▪️ WAF-Managed Rules
▪️ NACL
Event detection
▪️ GuardDuty
▪️ Macie
▪️ Network Firewall
Forensics and analytics
▪️ Detective
▪️ GuardDuty
▪️ Network Firewall
Integrity monitoring
▪️ ECR
▪️ Macie
▪️ Config Rules
▪️ Lambda function versioning
▪️ SSM State Manager
Inventory
▪️ ECR
▪️ Config
▪️ IAM credential report
▪️ SSM Inventory
Logging
▪️ Athena
▪️ CloudWatch
▪️ CloudWatch Logs
▪️ CloudWatch Logs Insights
▪️ OpenSearch Service
▪️ GuardDuty
▪️ Inspector
▪️ Lookout for Metrics
▪️ Macie
▪️ Route 53 Public Zone Logs and Resolver Query Logs
▪️ S3 Server Access Logs
▪️ VPC Flow Logs
▪️ Audit Manager
▪️ CloudTrail
▪️ CloudTrail Insights
▪️ Config
▪️ Config Rules
▪️ Security Hub
▪️ SSM Inventory
▪️ IAM Credential Report
▪️ SSM Session Logs
Mitigation and containment
▪️ EC2 Security Groups
▪️ Nitro Enclaves
Network protection
▪️ CloudFront
▪️ EC2 Security Groups
▪️ GuardDuty
▪️ Route 53 Resolver DNS Firewall
▪️ ALB
▪️ Firewall Manager
▪️ Network Firewall
▪️ Shield
▪️ WAF
▪️ WAF Automation
▪️ WAF-Managed Rules
▪️ NACL
Policy enforcement
▪️ Inspector
▪️ Config Rules
▪️ Lambda
▪️ SSM document
▪️ SSM Patch Manager
▪️ SSM State Manager
Reporting
▪️ SNS
Secure storage
▪️ Access Analyzer for S3
▪️ EBS
▪️ KMS
▪️ Macie
▪️ IAM
▪️ S3 Access Control Lists
▪️ S3 Bucket Policies
▪️ S3 Access Points
▪️ S3 Query string authentication
▪️ PrivateLink for S3
▪️ Storage Gateway
▪️ VPC endpoints
▪️ EFS
▪️ S3 Block Public Access
▪️ S3 Encryption
▪️ S3 MFA delete
▪️ S3 Object Lock
▪️ S3 Versioning
Virtual infrastructure
▪️ EBS snapshots
▪️ Backup
Vulnerability management
▪️ ECR image scanning
▪️ Inspector
▪️ Security Hub
Очень полезный документ, самые объёмные пункты по логированию, защите сети и шифрованию данных.
#security #NIST #devsecops
https://d1.awsstatic.com/whitepapers/Security/ransomware-risk-management-on-aws-using-csf.pdf
Если попытаться отразить все аспекты безопасности из данного документа в сервисах AWS, то получится следующий (длинный) список.
🔹 Basic
Use antivirus software at all times.
▪️ Marketplace
Keep computers fully patched.
▪️ SSM Patch Manager
Block access to ransomware sites.
▪️ Route 53 Resolver DNS Firewall
▪️ Network Firewall
▪️ NACL
Allow only authorized apps.
▪️ SSM State Manager
Use standard user accounts
▪️ IAM
Make an incident recovery plan.
▪️ AWS Security Incident Response Guide
Backup and restore.
▪️ EBS Snapshots
▪️ Backup
▪️ CloudEndure Disaster Recovery
▪️ CodeCommit
Keep your contacts.
▪️ AWS Security Incident Response Guide
🔸 NIST Practice Guide goals
Backup
▪️ EBS Snapshots
▪️ Backup
▪️ CloudEndure Disaster Recovery
▪️ CodeCommit
Corruption testing
▪️ Config Rules
▪️ SSM State Manager
Denylisting
▪️ EC2 Security Groups
▪️ Route 53 Resolver DNS Firewall
▪️ Network Firewall
▪️ VPC endpoints
▪️ WAF
▪️ WAF Security Automations
▪️ WAF-Managed Rules
▪️ NACL
Event detection
▪️ GuardDuty
▪️ Macie
▪️ Network Firewall
Forensics and analytics
▪️ Detective
▪️ GuardDuty
▪️ Network Firewall
Integrity monitoring
▪️ ECR
▪️ Macie
▪️ Config Rules
▪️ Lambda function versioning
▪️ SSM State Manager
Inventory
▪️ ECR
▪️ Config
▪️ IAM credential report
▪️ SSM Inventory
Logging
▪️ Athena
▪️ CloudWatch
▪️ CloudWatch Logs
▪️ CloudWatch Logs Insights
▪️ OpenSearch Service
▪️ GuardDuty
▪️ Inspector
▪️ Lookout for Metrics
▪️ Macie
▪️ Route 53 Public Zone Logs and Resolver Query Logs
▪️ S3 Server Access Logs
▪️ VPC Flow Logs
▪️ Audit Manager
▪️ CloudTrail
▪️ CloudTrail Insights
▪️ Config
▪️ Config Rules
▪️ Security Hub
▪️ SSM Inventory
▪️ IAM Credential Report
▪️ SSM Session Logs
Mitigation and containment
▪️ EC2 Security Groups
▪️ Nitro Enclaves
Network protection
▪️ CloudFront
▪️ EC2 Security Groups
▪️ GuardDuty
▪️ Route 53 Resolver DNS Firewall
▪️ ALB
▪️ Firewall Manager
▪️ Network Firewall
▪️ Shield
▪️ WAF
▪️ WAF Automation
▪️ WAF-Managed Rules
▪️ NACL
Policy enforcement
▪️ Inspector
▪️ Config Rules
▪️ Lambda
▪️ SSM document
▪️ SSM Patch Manager
▪️ SSM State Manager
Reporting
▪️ SNS
Secure storage
▪️ Access Analyzer for S3
▪️ EBS
▪️ KMS
▪️ Macie
▪️ IAM
▪️ S3 Access Control Lists
▪️ S3 Bucket Policies
▪️ S3 Access Points
▪️ S3 Query string authentication
▪️ PrivateLink for S3
▪️ Storage Gateway
▪️ VPC endpoints
▪️ EFS
▪️ S3 Block Public Access
▪️ S3 Encryption
▪️ S3 MFA delete
▪️ S3 Object Lock
▪️ S3 Versioning
Virtual infrastructure
▪️ EBS snapshots
▪️ Backup
Vulnerability management
▪️ ECR image scanning
▪️ Inspector
▪️ Security Hub
Очень полезный документ, самые объёмные пункты по логированию, защите сети и шифрованию данных.
#security #NIST #devsecops