Введение
Это третья часть серии статей, в которой рассматриваются некоторые основные службы, строительные блоки и подходы, которые помогут вам создать посадочную зону с несколькими учетными записями:
- Часть 1: Первоначальная настройка среды AWS с несколькими учетными записями
- Часть 2: Добавление AWS SSO и контроль разрешений
- Часть 3: Централизация соответствия нормативным требованиям и обнаружение инцидентов
- Часть 4: Бюджетные оповещения и отчетность
В этой статье мы сосредоточимся на некоторых сервисах, обеспечивающих безопасность, соответствие нормативным требованиям и обнаружение инцидентов, начиная с CloudTrail.
Используемый исходный код доступен в этом репозитории GitHub
CloudTrail
AWS CloudTrail — это служба AWS, которая помогает вам обеспечить управление, соответствие требованиям, а также операционный аудит и аудит рисков вашей учетной записи AWS. В данном демонстрационном примере мы создадим организационный след. Это след, который регистрирует все события для всех учетных записей AWS в организации. Они автоматически применяются ко всем учетным записям членов организации.
Чтобы создать организационный след, сначала необходимо включить CloudTrail в качестве доверенной службы в вашей организации, иначе вы получите сообщение об ошибке, как показано ниже:
ERROR: Resource OrgTrail failed because Resource handler returned
message: "Invalid request provided: The request could not be processed
because your organization hasn't enabled CloudTrail service access.
Enable service access for CloudTrail, and then try again.
Чтобы включить доверенный доступ, вы можете выполнить следующую команду, используя профиль в учетной записи управления:
aws organizations enable-aws-service-access --service-principal cloudtrail.amazonaws.com
Или вы можете настроить непосредственно из AWS Organizations в учетной записи управления, нажав на сервисы и выбрав CloudTrail, а затем включить доверенный доступ.
Включение доверенного доступа автоматически создает роль, связанную с сервисом, под названием AWSServiceRoleForCloudTrail роль в каждой учетной записи. Это необходимо для того, чтобы CloudTrail успешно регистрировал события для организации.
Журнал организации может быть настроен только в учетной записи управления, поэтому мы используем следующую OrganizationBinding, которая применяется только к этой учетной записи:
OrganizationBindings:
OrgTrailBinding:
IncludeMasterAccount: true
Мы также передаем в шаблон ряд параметров, которые включают указание имени для ведра S3, привязки организации и группы журналов CloudWatch. Кроме того, если мы еще не сделали этого, мы сохраняем organizationId нашей организации AWS в файле organization-parameters.yml и передаем это значение вместе с resource-prefix.
Parameters:
orgBucketName: !Sub '${resourcePrefix}-orgtrail-${CurrentAccount.AccountId}'
resourcePrefix: !Ref resourcePrefix
organizationId: !Ref organizationId
trailName: central-orgtrail
logGroupName: OrgTrail/org-audit-log
Теперь мы определим облачную информацию в самом главном шаблоне.
Создание S3 bucket в учетной записи управления
Сначала нам нужно создать S3 bucket, который будет получать файлы журналов для организационного следа. Мы используем настройки PublicAccessBlockConfiguration, чтобы заблокировать открытый публичный доступ к ведру. Мы используем настройки LifecycleConfiguration, чтобы хранить объекты только в течение определенного периода времени. Мы также настроим шифрование на стороне сервера с помощью управляемых S3 ключей и включим версионность.
OrgTrailBucket:
OrganizationBinding: !Ref OrgTrailBinding
Type: AWS::S3::Bucket
DeletionPolicy: Retain
UpdateReplacePolicy: Retain
Properties:
BucketName: !Ref orgBucketName
AccessControl: Private
PublicAccessBlockConfiguration:
BlockPublicAcls: true
BlockPublicPolicy: true
IgnorePublicAcls: true
RestrictPublicBuckets: true
LifecycleConfiguration:
Rules:
- ExpirationInDays: !Ref logDeletionDays
Id: 'orgtrail-bucket-lifecycle-configuration'
Status: Enabled
BucketEncryption:
ServerSideEncryptionConfiguration:
- ServerSideEncryptionByDefault:
SSEAlgorithm: AES256
VersioningConfiguration:
Status: Enabled
Этому ведру нужна политика ведра, которая позволяет CloudTrail помещать файлы журналов в ведро для организации. Ресурс с organizationId разрешает ведение журнала для организационного следа. Он также позволяет вести журнал для конкретной учетной записи в случае, если журнал будет изменен с журнала организации на журнал только для этой учетной записи. Условие aws:SourceArn помогает гарантировать, что CloudTrail может записывать в ведро S3 только для конкретного трейла.
- Sid: AWSCloudTrailAclCheck
Effect: Allow
Principal:
Service: cloudtrail.amazonaws.com
Action: s3:GetBucketAcl
Resource: !GetAtt OrgTrailBucket.Arn
- Sid: AWSCloudTrailWrite
Effect: Allow
Principal:
Service: cloudtrail.amazonaws.com
Action: s3:PutObject
Resource:
- !Sub '${OrgTrailBucket.Arn}/AWSLogs/${AWS::AccountId}/*'
- !Sub '${OrgTrailBucket.Arn}/AWSLogs/${organizationId}/*'
Condition:
StringEquals:
s3:x-amz-acl: bucket-owner-full-control
AWS:SourceArn: !Sub 'arn:aws:cloudtrail:eu-west-2:${AWS::AccountId}:trail/${trailName}'
Мы также хотим, чтобы наша организационная тропа поддерживала отправку событий в группу журналов CloudWatch. Перед настройкой трейла нам нужно настроить роль журнала CloudWatch и роль IAM, которую CloudTrail использует для записи в CloudWatch.
Начнем с создания группы журнала CloudWatch:
OrgTrailLogGroup:
OrganizationBinding: !Ref OrgTrailBinding
Type: 'AWS::Logs::LogGroup'
Properties:
RetentionInDays: 7
LogGroupName: !Ref logGroupName
Затем мы создадим роль IAM, которая будет использоваться CloudTrail. Это позволит CloudTrail создать поток журналов в указанной выше группе журналов и доставлять события в этот поток журналов как для трейлов в конкретной учетной записи AWS, так и для трейлов организации, созданных в этой учетной записи (учетной записи управления), которые применяются к организации с определенным organizationId.
OrgTrailLogGroupRole:
OrganizationBinding: !Ref OrgTrailBinding
Type: 'AWS::IAM::Role'
Properties:
RoleName: orgtrail-publish-to-cloudwatch-log-group
AssumeRolePolicyDocument:
Version: '2012-10-17'
Statement:
- Sid: AssumeRole1
Effect: Allow
Principal:
Service: 'cloudtrail.amazonaws.com'
Action: 'sts:AssumeRole'
Policies:
- PolicyName: 'cloudtrail-policy'
PolicyDocument:
Version: '2012-10-17'
Statement:
- Sid: AWSOrgTrailCreateLogStream
Effect: Allow
Action:
- 'logs:CreateLogStream'
- 'logs:PutLogEvents'
Resource:
- !Sub 'arn:aws:logs:eu-west-2:${AWS::AccountId}:log-group:${logGroupName}:log-stream:${AWS::AccountId}_CloudTrail_eu-west-2*'
- !Sub 'arn:aws:logs:eu-west-2:${AWS::AccountId}:log-group:${logGroupName}:log-stream:${organizationId}_*'
Наконец, мы создаем тропу, предоставляя всю необходимую информацию
OrgTrail:
OrganizationBinding: !Ref OrgTrailBinding
Type: AWS::CloudTrail::Trail
DependsOn:
- OrgTrailBucketPolicy
- OrgTrailLogGroup
- OrgTrailLogGroupRole
Properties:
CloudWatchLogsLogGroupArn: !GetAtt 'OrgTrailLogGroup.Arn'
CloudWatchLogsRoleArn: !GetAtt 'OrgTrailLogGroupRole.Arn'
EnableLogFileValidation: true
IncludeGlobalServiceEvents: true
IsLogging: true
IsMultiRegionTrail: true
IsOrganizationTrail: true
S3BucketName: !Ref OrgTrailBucket
TrailName: !Ref trailName
По умолчанию трассы, созданные без определенных селекторов событий, будут настроены на регистрацию всех событий управления чтением и записью, и никаких событий данных. События данных дают представление об операциях на ресурсе («плоскость данных»), выполняемых на самом ресурсе или внутри него. События данных часто представляют собой действия большого объема и включают такие операции, как API на уровне объектов Amazon S3 и API вызова функций Lambda.
Добавление следующего EventSelector в раздел свойств приведет к регистрации событий данных для всех объектов во всех ведрах S3 в вашей учетной записи, при этом будут регистрироваться как события чтения и записи, так и события управления.
...
Properties:
EventSelectors:
- DataResources:
- Type: AWS::S3::Object
Values:
- !Sub "arn:aws:s3:::"
IncludeManagementEvents: true
ReadWriteType: All
После запуска конвейера и создания организационного трейла в каждой учетной записи AWS, принадлежащей организации, будет создан трейл с заданным именем. Пользователи с соответствующими правами смогут увидеть этот след в своих учетных записях членов организации и смогут просматривать историю событий непосредственно в CloudTrail для своей учетной записи. Однако они не смогут удалить или изменить этот след каким-либо образом. Любая попытка сделать это приведет к появлению сообщения об ошибке, как показано в консоли ниже:
По умолчанию файлы журналов, доставляемые CloudTrail в ваше ведро, шифруются с помощью шифрования на стороне сервера Amazon с использованием управляемых Amazon S3 ключей шифрования (SSE-S3). Для обеспечения уровня безопасности, которым можно управлять напрямую, вы можете использовать шифрование на стороне сервера с ключами шифрования AWS KMS (SSE-KMS) для ваших файлов журналов CloudTrail, но это уже выходит за рамки данного блога.
Сигналы тревоги CloudWatch
В нашей второй статье мы показали, как настроить роль между учетными записями, чтобы пользователь из группы IncidentResponse в учетной записи Security мог переходить в производственную учетную запись для проведения расследования в случае инцидента. Чтобы добавить дополнительный уровень безопасности и аудита, мы настроим сигнализацию CloudWatch, которая будет оповещать нас каждый раз, когда будет использована повышенная роль.
Для начала мы определим сигнал тревоги CloudWatch, который будет существовать в учетной записи управления с централизованными журналами CloudWatch из CloudTrail. Мы указываем имя метрики, связанной с сигналом тревоги. Статистика — это совокупность данных метрики за определенные периоды времени. Для этого сигнала тревоги мы просто суммируем значения всех точек данных за период времени в 10 секунд. Мы проводим оценку только за 1 период. Это означает, что если за 10-секундный период произойдет один инцидент, сигнал тревоги будет подан.
RoleAlarm:
Type: AWS::CloudWatch::Alarm
OrganizationBinding: !Ref OrgTrailBinding
Properties:
AlarmName: 'Security switched to Elevated Role in Prod'
AlarmDescription: 'Alarm on usage of elevated role in the Prod account'
MetricName: !Sub '${resourcePrefix}-switch-elevated-count'
Namespace: OrgTrailMetrics
Statistic: Sum
Period: 10
EvaluationPeriods: 1
Threshold: 1
TreatMissingData: notBreaching
AlarmActions:
- !Ref AlarmNotificationTopic
ComparisonOperator: GreaterThanOrEqualToThreshold
Затем мы определяем фильтр MetricFilter. Этот фильтр ищет в группе журналов CloudWatch любые события, в которых имя события — ‘SwitchRole’, а предполагаемая роль — ‘elevated-security-role’.
ProductionSupportRoleLoginsFilter:
Type: AWS::Logs::MetricFilter
OrganizationBinding: !Ref OrgTrailBinding
Properties:
LogGroupName: !Ref logGroupName
FilterPattern: '{($.eventName = "SwitchRole") && ($.userIdentity.arn = "arn:aws:sts::*:assumed-role/elevated-security-role/*") }'
MetricTransformations:
- MetricValue: '1'
MetricNamespace: OrgTrailMetrics
MetricName: !Sub '${resourcePrefix}-switch-elevated-count'
Наконец, мы определяем тему SNS, куда будет отправлено уведомление в случае срабатывания сигнала тревоги. Здесь настроена отправка электронного письма на наш корневой адрес электронной почты.
AlarmNotificationTopic:
Type: AWS::SNS::Topic
OrganizationBinding: !Ref OrgTrailBinding
Properties:
DisplayName: !Sub 'Notifies when alarm on usage of elevated role goes off'
TopicName: !Sub '${resourcePrefix}-switch-elevatedrole-alarm-notification'
Subscription:
- Endpoint: !GetAtt MasterAccount.RootEmail
Protocol: email
Теперь мы можем войти в учетную запись Security как пользователь из группы IncidentResponse и переключить роль в консоли на повышенную роль безопасности в учетной записи Production. Это приведет к срабатыванию нашего сигнала тревоги, который мы можем увидеть в консоли CloudWatch Alarm:
И когда мы увидим, что это тревога, мы также должны получить электронное письмо, уведомляющее нас об использовании роли повышенной безопасности в production.
В этот момент мы можем использовать CloudTrail для просмотра всех действий, которые были выполнены пользователем, или предпринять какие-либо другие действия. Это дает вам представление о возможностях, которые существуют при использовании CloudTrail. Теперь мы перейдем к конфигурации AWS Config.
AWS Config
AWS Config — это служба, которая позволяет вам постоянно оценивать, аудировать и анализировать конфигурации ваших ресурсов AWS. Это включает в себя то, как ресурсы связаны друг с другом, а также то, как они были настроены в прошлом и изменялись с течением времени.
Для начала мы создаем ведро S3 в учетной записи Log Archive и прикрепляем к нему политику ведра, которая позволяет службе Config помещать объекты в это ведро, как показано здесь. Чтобы включить AWS Config, мы должны создать регистратор конфигурации и канал доставки. AWS Config использует канал доставки для доставки изменений конфигурации в ваше ведро Amazon S3.
В записи конфигурации описываются типы ресурсов AWS, для которых мы хотим записывать изменения конфигурации. В группе записи мы указываем, что AWS Config будет записывать изменения конфигурации для каждого поддерживаемого типа региональных ресурсов. Она также будет включать все поддерживаемые типы глобальных ресурсов, такие как IAM.
ConfigurationRecorder:
Type: 'AWS::Config::ConfigurationRecorder'
Properties:
RecordingGroup:
AllSupported: true
IncludeGlobalResourceTypes: true
RoleARN: !GetAtt ConfigurationRecorderRole.Arn
Канал доставки используется для доставки информации о конфигурации в наше ведро S3 (он также поддерживает SNS). Мы настроили его на доставку снимков конфигурации каждый час в ведро S3.
DeliveryChannel:
Type: 'AWS::Config::DeliveryChannel'
Properties:
ConfigSnapshotDeliveryProperties:
DeliveryFrequency: One_Hour
S3BucketName: !Ref ConfigAuditBucket
Мы также настраиваем роль IAM, которую будет принимать Config. Сюда входит управляемая AWS политика AWSConfigRole, которая гарантирует, что Config будет иметь необходимые разрешения для получения деталей конфигурации всякий раз, когда будет поддерживаться новый тип ресурса AWS. Политика также позволяет Config записывать подробности в ведро S3.
ConfigurationRecorderRole:
Type: 'AWS::IAM::Role'
Properties:
ManagedPolicyArns:
- 'arn:aws:iam::aws:policy/service-role/AWSConfigRole'
AssumeRolePolicyDocument:
Version: '2012-10-17'
Statement:
- Sid: AssumeRole1
Effect: Allow
Principal:
Service: 'config.amazonaws.com'
Action: 'sts:AssumeRole'
Policies:
- PolicyName: 's3-policy'
PolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: Allow
Action: 's3:PutObject'
Resource: !Sub '${ConfigAuditBucket.Arn}/*'
Condition:
StringLike:
's3:x-amz-acl': 'bucket-owner-full-control'
- Effect: Allow
Action: 's3:GetBucketAcl'
Resource: !GetAtt ConfigAuditBucket.Arn
Мы можем нажать на изменения для развертывания конвейера, и теперь AWS Config будет включен и развернут на всех учетных записях в наших организациях. Вы можете зайти в любую учетную запись и просмотреть ресурсы через приборную панель. Однако в настоящее время нет проверок соответствия, поскольку мы не определили никаких правил. Так что давайте сделаем это.
Управляемые правила AWS Config
AWS Config предоставляет управляемые правила AWS, которые представляют собой предопределенные, настраиваемые правила, которые AWS Config использует для оценки соответствия ваших ресурсов AWS общим лучшим практикам. После активации правила AWS Config сравнивает ваши ресурсы с условиями правила. После этой первоначальной оценки AWS Config продолжает выполнять оценки каждый раз, когда срабатывает одно из них.
Мы настроим соответствие с управляемым правилом AWS для проверки доступности входящего трафика SSH для группы безопасности. Вы можете найти здесь список управляемых правил AWS Config. Мы будем использовать правило restricted-ssh, которое имеет идентификатор INCOMING_SSH_DISABLED. Оно настраивается с помощью cloudformation в приведенном ниже шаблоне. Оно распространяется на все учетные записи.
SSHOrganizationConfigRule:
Type: "AWS::Config::OrganizationConfigRule"
Properties:
OrganizationConfigRuleName: "OrganizationRestrictedSSH"
OrganizationManagedRuleMetadata:
RuleIdentifier: "INCOMING_SSH_DISABLED"
Description: "restricted-ssh"
Настраивать множество отдельных управляемых правил может быть утомительно и чревато ошибками, поэтому AWS также предоставляет пакеты соответствия, которые мы сейчас рассмотрим.
Пакет соответствия AWS Config
Пакет соответствия — это набор правил AWS Config и действий по устранению несоответствий, которые можно легко развернуть как единое целое в учетной записи и регионе или в организации в AWS Organizations. Пакеты соответствия создаются путем создания шаблона YAML, который содержит список управляемых или пользовательских правил AWS Config и действий по устранению последствий.
AWS предоставляет набор образцов шаблонов для пакетов соответствия. Мы будем использовать ‘Operational Best Practices for Security, Identity and Compliance Services’. Шаблон доступен в этом репозитории GitHub
Шаги по включению пакета соответствия просты. Во-первых, мы вызываем шаблон, который создает ведро S3 в учетной записи управления.
CompliancePackBucket:
Type: AWS::S3::Bucket
DeletionPolicy: Retain
UpdateReplacePolicy: Retain
Properties:
BucketName: !Ref bucketName
AccessControl: Private
PublicAccessBlockConfiguration:
BlockPublicAcls: true
BlockPublicPolicy: true
IgnorePublicAcls: true
RestrictPublicBuckets: true
BucketEncryption:
ServerSideEncryptionConfiguration:
- ServerSideEncryptionByDefault:
SSEAlgorithm: AES256
Затем мы копируем пакет соответствия с GitHub в локальный файл yml. Затем мы запускаем задачу для копирования этого файла в ведро S3.
CopyToS3:
Type: copy-to-s3
DependsOn: ConfigCompliancePackBucket
LocalPath: ./Operational-Best-Practices-for-Security-Services.yml
RemotePath: !Sub 's3://${resourcePrefix}-conformance-pack/security-services.yml'
OrganizationBinding:
IncludeMasterAccount: true
Region: eu-west-2
Наконец, мы вызываем шаблон, который использует ресурс OrganizationConformancePack для развертывания шаблона в ведре S3 в организации.
OrganizationConformancePack:
Type: AWS::Config::OrganizationConformancePack
Properties:
OrganizationConformancePackName: SecurityServices
TemplateS3Uri: !Ref templateURI
После развертывания нам доступна гораздо более богатая информация о статусе соответствия наших ресурсов.
Агрегатор AWS Config
Агрегатор — это тип ресурса AWS Config, который может собирать данные о конфигурации и соответствии AWS Config от организации в AWS Organizations. Это позволит нам централизовать все данные Config в нашей учетной записи Security.
Чтобы настроить агрегатор, сначала нужно зайти в AWS Organizations в учетной записи управления, нажать на сервисы, выбрать Config, а затем включить доверенный доступ.
Затем мы определяем учетную запись Security в качестве делегированного администратора для Config с помощью следующей команды в окне терминала:
aws organizations register-delegated-administrator --account-id <security-account-id> --service-principal config.amazonaws.com
Затем мы определяем роль IAM, которая будет использоваться службой Config. Эта роль должна иметь политику AWSConfigRoleForOrganizations. Эта роль предназначена для учетной записи Security:
ConfigAggregatorRole:
Type: AWS::IAM::Role
OrganizationBinding: !Ref SecurityBinding
Properties:
RoleName: !Sub '${resourcePrefix}-configaggregator-role'
AssumeRolePolicyDocument:
Version: 2012-10-17
Statement:
- Effect: Allow
Principal:
Service: config.amazonaws.com
Action:
- sts:AssumeRole
Path: /
ManagedPolicyArns:
- 'arn:aws:iam::aws:policy/service-role/AWSConfigRoleForOrganizations'
Далее мы определяем сам агрегатор для учетной записи Security. Мы используем свойство OrganizationAggregationSource, чтобы определить, что это для организации. В нашем случае мы просто собираем данные для одного региона.
ConfigAggregator:
Type: AWS::Config::ConfigurationAggregator
OrganizationBinding: !Ref SecurityBinding
DependsOn: ConfigAggregatorRole
Properties:
OrganizationAggregationSource:
RoleArn: !GetAtt ConfigAggregatorRole.Arn
AwsRegions:
- !Ref aggregatorRegion
AllAwsRegions: false
ConfigurationAggregatorName: OrgConfigAggregator
После развертывания агрегатор появится в учетной записи Security и начнет собирать данные конфигурации из других учетных записей. Теперь начинается тяжелая работа по обеспечению соответствия ваших ресурсов требованиям.
Одно из правил, которое отмечено как несоответствующее, — не включенный GuardDuty, поэтому сейчас мы рассмотрим именно это.
Amazon GuardDuty
Amazon GuardDuty — это служба обнаружения угроз, которая постоянно отслеживает ваши учетные записи и рабочие нагрузки AWS на предмет вредоносной активности и предоставляет подробные выводы по безопасности для наглядности и исправления ситуации.
Начнем с настройки нового детектора (объекта, представляющего службу GuardDuty), который необходим для начала работы GuardDuty. Он развертывается на все учетные записи в организации. Детектор должен быть включен при создании и будет экспортировать обновленные результаты каждые 15 минут.
Detector:
Type: AWS::GuardDuty::Detector
OrganizationBinding: !Ref GuardDutyAllBinding
Properties:
Enable: true
FindingPublishingFrequency: FIFTEEN_MINUTES
Затем мы настраиваем ресурс AWS::GuardDuty::Master в каждой учетной записи участника GuardDuty на получение приглашения от учетной записи администратора GuardDuty, которая назначена как учетная запись безопасности.
Master:
DependsOnAccount: !Ref SecurityAccount
Type: AWS::GuardDuty::Master
OrganizationBinding: !Ref GuardDutyMemberBinding
Properties:
DetectorId: !Ref Detector
MasterId: !Ref SecurityAccount
Наконец, мы настраиваем ресурс AWS::GuardDuty::Member для добавления учетной записи AWS в качестве учетной записи-члена GuardDuty к учетной записи администратора GuardDuty. Это развертывается только для учетной записи Security, но в цикле для всех других учетных записей AWS передаются идентификаторы учетных записей для добавления в качестве членов.
Member:
Type: AWS::GuardDuty::Member
OrganizationBinding: !Ref GuardDutyMasterBinding
ForeachAccount: !Ref GuardDutyMemberBinding
Properties:
DetectorId: !Ref Detector
Email: !GetAtt CurrentAccount.RootEmail
MemberId: !Ref CurrentAccount
Status: Invited
DisableEmailNotification: true
После развертывания мы можем зайти в раздел Accounts консоли GuardDuty в учетной записи Security и увидеть все остальные учетные записи-участники. Результаты работы GuardDuty автоматически отправляются в CloudWatch Events. Теперь мы рассмотрим, как отправить простое уведомление при возникновении инцидента. Начнем с указания правила события на стандартном Amazon EventBridge.
FindingRule:
Type: AWS::Events::Rule
DependsOn: FindingsTopicPolicy
OrganizationBinding: !Ref GuardDutyMasterBinding
Properties:
Name: !Sub '${resourcePrefix}-guardduty-findings-rule'
EventPattern:
source:
- aws.guardduty
Targets:
- Id: FindingsTopic
Arn: !Ref FindingsTopic
State: ENABLED
Приведенное выше правило ищет любое событие, опубликованное службой GuardDuty. Если событие найдено, оно пересылает его в тему SNS. Вы можете развлечься, рассматривая различные правила с шаблонами событий в EventBridge, в том числе используя примеры выводов GuardDuty. Вы можете использовать приведенный ниже шаблон для запуска уведомления для определенного типа находок:
EventPattern:
source:
- aws.guardduty
detail:
type:
- UnauthorizedAccess:EC2/MaliciousIPCaller.Custom
Можно использовать шаблон, подобный приведенному ниже, для запуска уведомления, если серьезность обнаружения превышает определенный порог.
EventPattern:
source:
- aws.guardduty
detail.severity:
- numeric:
- ">"
- 6
Наконец, мы определяем тему SNS в шаблоне cloudformation, которая будет использоваться для запуска уведомления по электронной почте при получении находки.
FindingsTopic:
Type: AWS::SNS::Topic
OrganizationBinding: !Ref GuardDutyMasterBinding
Properties:
DisplayName: GuardDuty Findings
TopicName: !Sub '${resourcePrefix}-guardduty-findings-notification'
Subscription:
- Protocol: email
Endpoint: !GetAtt SecurityAccount.RootEmail
Мы можем проверить это, войдя в одну из учетных записей AWS, используя корневой адрес электронной почты. Этого следует избегать, и это вызовет обнаружение GuardDuty для RootCredentialUsage.
В этой статье мы затронули ряд служб AWS, которые помогают в аудите и соблюдении нормативных требований, а также в обнаружении и реагировании на инциденты. Это очень обширная тема с доступными мощными функциями. В следующем посте мы начнем рассматривать бюджеты и мир FinOps и устойчивого развития с помощью отчетов Cost и Usage Reports.