🔐

【AWS】アカウント作成後にセキュリティ関連でやること

2022/08/29に公開

はじめに

  • 作成直後のAWSアカウントには以外とリスクが潜んでいます
  • リスクを低減するためにできることはやっておきましょう!

アカウント作成後にやること

✅ 1.ルートユーザのMFA有効化

  • ルートユーザへ攻撃者がログインできてしまうと何でもできてしまいます
  • MFAを有効化することでルートユーザの乗っ取りを防止しましょう

https://aws.amazon.com/jp/premiumsupport/knowledge-center/potential-account-compromise/

考慮事項

不正利用時の対処方法確立

  • ルートユーザが乗っ取られた場合、不正利用された場合の対応を検討しておくことを推奨
    • エンタープライスサポート等を契約していれば、サポートケースを起票してルートアカウントのパスワードを変更してもらうことになると思います

ルートユーザを利用しない運用の検討

  • IAMユーザ(なるべくIDプロバイダー経由のIAMロール)を利用しましょう

https://aws.amazon.com/jp/blogs/startup/techblog-iam-sso-practice/

SCPでの制限

  • Organizationsを利用している場合は、SCPでメンバーアカウントのルートユーザの操作をある程度(以下URL参照)制限することが可能です
    • マネジメントアカウント側は制御不能です

https://docs.aws.amazon.com/ja_jp/organizations/latest/userguide/orgs_manage_policies_scps.html#not-restricted-by-scp

✅ 2.ルートユーザのログイン通知

  • MFA有効化後はルートユーザを利用する場面はほぼ無いと思います
    • 契約関連、支払い関連で必要となる場合はあります
  • ルートユーザのログイン通知機能を実装することで不正利用を検知することができます

https://aws.amazon.com/jp/premiumsupport/knowledge-center/root-user-account-eventbridge-rule/

✅ 3.CloudTrail有効化

  • 誰が(IAMユーザもしくはIAMロール)何のAPIを発行したのかを追跡できます

https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/cloudtrail-integration.html

  • 以下のイベントでは JaneDoe ユーザが us-east-2 リージョンで GetUserPolicy APIを呼び出したことが分かります
{
  "eventVersion": "1.05",
  "userIdentity": {
    "type": "IAMUser",
    "principalId": "AIDACKCEVSQ6C2EXAMPLE",
    "arn": "arn:aws:iam::444455556666:user/JaneDoe",
    "accountId": "444455556666",
    "accessKeyId": "AKIAI44QH8DHBEXAMPLE",
    "userName": "JaneDoe",
    "sessionContext": {
      "attributes": {
        "mfaAuthenticated": "false",
        "creationDate": "2014-07-15T21:39:40Z"
      }
    },
    "invokedBy": "signin.amazonaws.com"
  },
  "eventTime": "2014-07-15T21:40:14Z",
  "eventSource": "iam.amazonaws.com",
  "eventName": "GetUserPolicy",
  "awsRegion": "us-east-2",
  "sourceIPAddress": "signin.amazonaws.com",
  "userAgent": "signin.amazonaws.com",
  "requestParameters": {
    "userName": "JaneDoe",
    "policyName": "ReadOnlyAccess-JaneDoe-201407151307"
  },
  "responseElements": null,
  "requestID": "9EXAMPLE-0c68-11e4-a24e-d5e16EXAMPLE",
  "eventID": "cEXAMPLE-127e-4632-980d-505a4EXAMPLE"
} 
  • 例えばマイニングの不正利用があった際に、どのリージョンでどのEC2が起動されたのかを追跡することができます

考慮事項

全リージョンでの有効化

  • 攻撃者からすると不正利用に気付かれたくありません。気付かれないように普段利用されていないリージョンで攻撃を実施する可能性が高いので、全てのリージョン(香港等のオプトインリージョンは除く)での有効化を推奨
    • マネジメントコンソール経由だと自動的に全てのリージョンになるので、CLIやterraform等で構築している人は注意

https://docs.aws.amazon.com/ja_jp/awscloudtrail/latest/userguide/cloudtrail-create-a-trail-using-the-console-first-time.html

Data Eventの記録

  • Data Eventの記録はコストと要件見合いで要検討
    • S3のオブジェクト操作ログ、Lambdaの関数呼び出しログ、DynamoDBのアイテム操作ログ

https://aws.amazon.com/jp/premiumsupport/knowledge-center/cloudtrail-data-management-events/

ログの保持期間

  • 有効化しただけでは90日分しか確認できません
  • コストと要件次第ですが、S3バケットに出力することで無期限に保持が可能です
    • CloudTrailの標準機能で可能
  • また、AthenaもしくはCloudTrail Lakeで検索できるようにしておくと、いざログを検索するというときに焦らずに済みます

https://docs.aws.amazon.com/ja_jp/athena/latest/ug/cloudtrail-logs.html#create-cloudtrail-table-ct

https://docs.aws.amazon.com/ja_jp/awscloudtrail/latest/userguide/cloudtrail-lake.html

✅ 4.SecurityHub有効化

  • 本記事では後続のGuardDutyの検出結果を集約する目的で利用を推奨します
    • クロスリージョン集約を利用して全リージョンの結果を集約しましょう

https://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/finding-aggregation.html

  • SecurityHub自体には セキュリティ標準とコントロール機能 があり、CISベンチマーク等のチェックが可能です

https://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/securityhub-standards.html

✅ 5.GuardDuty有効化

  • マイニングなどの攻撃を検知することができます

  • Route53のDNSクエリログ、VPC Flow Log、CloudTrailログを利用して検知以上します

    • 上記ログはGuardDutyのサービスリンクロール経由で自動取得してくれるため、アカウント、リソース側でログ出力設定をしていなくても問題ありません
  • 検知可能な攻撃は以下を参照
    https://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/guardduty_finding-types-active.html

  • 2022/07にはマルウェア検知機能も追加されました

https://aws.amazon.com/jp/about-aws/whats-new/2022/07/malware-protection-feature-amazon-guardduty/

考慮事項

全リージョンでの有効化

  • こちらもCloudTrail同様全リージョンでの有効化を推奨
  • 検出結果は自動的にSecurityHubにImportされるので、SecurityHub側のリージョン集約機能を活用することで可視性が向上します

検知後の運用の検討

  • GuardDutyで検知までは行えますが、その後の対応はできません
  • 検知後の対応を誰が行うのか(ex. SoC、CCoE、アカウント管理者)を検討しておくのが望ましいです

✅ 6.AWS Config有効化

  • リソース(ex. あるEC2インスタンス)の設定変更履歴を追跡することができます
  • 不正利用時にどのような操作が行われたのかをリソース観点から調査することができます(CloudTrailだとAPI観点が主)

考慮事項

全リージョンでの有効化

  • こちらも全リージョンでの有効化を推奨

以上

Discussion