0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@namnam3225(Naoki Matsumoto)

AWSセキュリティの基本｜何から確認して、どう改善するか

0
Posted at

AWSセキュリティの基本｜何から確認して、どう改善するか

AWSのセキュリティ対策では、まず次のような対策を行います。

  • 認証・アクセスを保護する

    • ルートユーザーにMFAを設定する
    • IAM Identity Centerで人のアクセスを管理する
    • IAMを最小権限にする
    • 不要なアクセスキーを削除する

  • 操作を記録する

    • CloudTrailで操作履歴を記録する

  • 外部公開範囲を制限する

    • Security Groupの公開範囲を確認する
    • S3が意図せず公開されていないか確認する

  • データを保護する

    • S3、EBS、RDSなどの保存データを暗号化する
    • HTTPSを利用する

  • 不審な挙動や脆弱性を検知する

    • GuardDutyで不審な挙動を確認する
    • Amazon Inspectorで脆弱性を確認する

  • セキュリティ状況をまとめて確認する

    • Security Hubでセキュリティ上の問題を確認する

  • 検知した問題を通知する

    • EventBridgeやSNSなどを利用して担当者へ通知する

この記事では「IAMを確認しましょう」で終わらせず、

  • AWSマネジメントコンソールのどこを見るのか
  • 何を確認するのか
  • 問題があったら何を変更するのか
  • Terraformで管理している場合はどう考えるのか

まで具体的に見ていきます。

なぜこの順番で確認するのか

AWSのセキュリティ対策は、すべてを同時に進めるのではなく、
影響の大きさや緊急性を考えて優先順位を付けて進めます。

ここでは、次の順番で確認していきます。

  • 認証・権限

    • 侵害された場合にAWSアカウント全体へ影響する可能性があるため、最初に確認する

  • 記録

    • 問題発生後に過去の操作ログを作ることはできないため、早い段階で確認する

  • 外部公開

    • Security GroupやS3などが意図せずインターネットへ公開されていないか確認する

  • データ保護

    • 保存データの暗号化やHTTPSを確認し、データ自体を保護する

  • 検知・通知

    • GuardDutyやInspectorなどで問題を継続的に検知し、発生時に対応できる状態にする

認証・権限 → 記録 → 外部公開 → データ保護 → 検知・通知

まず何をすればいい？

AWS環境のセキュリティをこれから確認するなら、まずは次の順番で確認します。

  1. ルートユーザーのMFAとアクセスキーを確認する
  2. IAM Identity Centerで人のAWSアクセスを確認する
  3. IAMの不要な権限・アクセスキーを確認する
  4. CloudTrailで操作を追跡できる状態か確認する
  5. Security Groupの0.0.0.0/0や::/0を確認する
  6. S3のPublic Accessを確認する
  7. S3・EBS・RDSの暗号化を確認する
  8. ALBなどのHTTPS設定を確認する
  9. GuardDutyのFindingを確認する
  10. InspectorのCritical / Highを確認する
  11. Security Hubで全体の問題を確認する
  12. 問題が発生したときの通知を設定する

では、それぞれ実際の確認方法を見ていきます。

1. ルートユーザーにMFAを設定する

ルートユーザーはAWSアカウントに対して非常に強い権限を持っています。

そのため、

  • MFAを設定する
  • 通常作業では使用しない
  • ルートユーザーのアクセスキーを作成しない
  • 認証情報を適切に管理する

という対策を行います。

AWSマネジメントコンソールで確認する

まず、ルートユーザーのMFAが設定されているか確認します。

確認する場所は、AWSマネジメントコンソールのアカウントのセキュリティ認証情報です。

確認するポイントは、

  • MFAが登録されているか
  • ルートユーザーのアクセスキーが不要に作成されていないか
  • 普段の作業でルートユーザーを利用していないか

です。

MFAが設定されていなければ、MFAデバイスを登録します。

Terraformで設定するの？

ここは少し注意が必要です。

ルートユーザーのMFA登録そのものは、通常のTerraformによるインフラ構築とは分けて考えます。

Terraformで管理するというより、AWSアカウントを作成したときに実施する初期セキュリティ設定として扱います。

つまり、

  • ルートユーザーのMFA → AWSアカウントの初期設定
  • IAM RoleやPolicy → Terraformで管理可能

というように分けて考えると分かりやすいでしょう。

2. 人のAWSアクセスを整理する

複数人でAWSを利用している場合は、誰がどのAWSアカウントへアクセスできるのか確認します。

IAM Identity Centerを利用している場合は、

  • Users
  • Groups
  • Permission sets
  • AWS accountsへの割り当て

を確認します。

AWSマネジメントコンソールで確認する

AWSマネジメントコンソールからIAM Identity Centerを開きます。

まずUsersやGroupsを確認して、

  • 退職したユーザーが残っていないか
  • 不要なユーザーが存在しないか
  • 適切なグループに所属しているか

を確認します。

次にPermission setsを確認します。

例えば、

  • AdministratorAccess
  • PowerUserAccess
  • ReadOnlyAccess
  • 独自のPermission Set

など、どの権限が用意されているか確認します。

さらにAWS accountsから、

誰が、どのAWSアカウントに、どのPermission Setでアクセスできるのか

を確認します。

不要な割り当てがあれば削除します。

3. 強すぎるIAM権限を減らす

次にIAMユーザーやIAM Roleへ付与されている権限を確認します。

ここで重要なのは、

S3の権限だからS3を確認するわけではない

ということです。

権限そのものはIAMで確認します。

AWSマネジメントコンソールで確認する

AWSマネジメントコンソールからIAMを開きます。

人に付与された権限なら、

  • IAM
  • Users
  • 対象ユーザー
  • Permissions

を確認します。

IAM Roleの場合は、

  • IAM
  • Roles
  • 対象Role
  • Permissions

を確認します。

例えば、

AdministratorAccess

や、

AmazonS3FullAccess

などが付与されていないか確認します。

S3からファイルを読むだけのアプリケーションなのにAmazonS3FullAccessが付いているのであれば、必要以上の権限を持っている可能性があります。

必要な操作がGetObjectだけなら、例えばs3:GetObjectだけを許可するPolicyへ変更できないか検討します。

また、実際に利用されている権限を確認しながら権限を絞り込む場合は、IAM Access Analyzerも利用できます。

単純に強いPolicyを削除するのではなく、

実際に必要な操作は何か

を確認しながら最小権限にしていくことが重要です。

Terraformで管理している場合

IAM RoleやIAM PolicyをTerraformで作成している場合は、AWSコンソールで直接修正するのではなくTerraform側を変更します。

例えば確認するのは、

  • aws_iam_role
  • aws_iam_policy
  • aws_iam_role_policy
  • aws_iam_role_policy_attachment

などです。

AWSコンソールは現在の状態を確認するために利用し、実際の変更はTerraformへ反映します。

そうしないと、

Terraform上の設定とAWS上の設定が違う

という状態になるためです。

4. 不要なアクセスキーを削除する

次にIAMユーザーのアクセスキーを確認します。

AWSマネジメントコンソールで確認する

AWSマネジメントコンソールから、

  • IAM
  • Users
  • 対象ユーザー
  • Security credentials

を開きます。

Access keysから、

  • アクセスキーが存在するか
  • Activeになっているか
  • 最後にいつ利用されたか
  • 本当に現在も利用されているか

を確認します。

長期間利用されていないアクセスキーが見つかった場合は、何に利用しているものなのか確認します。

不要であれば無効化し、問題がないことを確認したうえで削除します。

また、EC2やLambdaなどAWS上のサービスからAWSへアクセスするためにアクセスキーを利用している場合は、IAM Roleへ変更できないか検討します。

5. CloudTrailで操作履歴を確認する

次に、AWS上で行われた操作を追跡できる状態になっているか確認します。

CloudTrailを早い段階で確認する理由は、問題が発生したときに操作履歴を調査できるようにするためです。

何か起きてからログを残そうとしても、必要な過去のログを後から作ることはできません。

AWSマネジメントコンソールで確認する

AWSマネジメントコンソールから、

  • CloudTrail
  • Event history

を開きます。

例えばEC2が削除された原因を調べたい場合は、

TerminateInstances

を検索します。

イベントを開くと、

  • Event time
  • Event name
  • Username
  • Source IP address
  • Resources

などを確認できます。

CloudTrailのEvent historyでは、過去90日間のManagement eventsを確認できます。

そのため、直近の操作履歴を確認するだけであればEvent historyを利用できます。

一方で、

  • 90日を超えてログを保存したい
  • 継続的にログをS3へ保存したい
  • Data eventsなども記録したい

といった場合は、Event historyだけではなくTrailやCloudTrail Lakeの設定も確認します。

Trailを利用している場合は、

  • Trailが存在するか
  • ログの保存先S3 Bucket
  • 対象リージョン
  • ログ取得設定

などを確認します。

6. Security Groupの公開範囲を確認する

次にネットワークの公開範囲を確認します。

AWSマネジメントコンソールで確認する

AWSマネジメントコンソールから、

  • EC2
  • Network & Security
  • Security Groups

を開きます。

対象のSecurity Groupを選択し、Inbound rulesを確認します。

特に、

0.0.0.0/0

またはIPv6の、

::/0

が設定されているルールを確認します。

例えば、

  • SSH（22）
  • RDP（3389）
  • MySQL（3306）
  • PostgreSQL（5432）

などがインターネット全体へ公開されていた場合、本当に必要なのか確認します。

不要なら削除します。

必要な場合でも、

  • 接続元IPを限定する
  • 別のSecurity Groupからだけ許可する
  • Session Managerなど別の接続方法を利用する

といった方法を検討します。

TerraformでSecurity Groupを管理している場合は、aws_security_groupや関連するSecurity Group Ruleの定義を修正します。

7. S3が意図せず公開されていないか確認する

次にS3の公開設定を確認します。

AWSマネジメントコンソールで確認する

AWSマネジメントコンソールから、

  • S3
  • Buckets
  • 対象Bucket
  • Permissions

を開きます。

主に、

  • Block Public Access
  • Bucket Policy
  • ACL

を確認します。

公開する必要がないBucketでPublic Accessが許可されていないか確認します。

Bucket Policyについても、

Principal: "*"

など、不特定の主体へアクセスを許可している設定がないか確認します。

公開する必要がなければ、Block Public Accessを有効にし、不要なBucket PolicyやACLを修正します。

また、Bucket単位だけでなく、AWSアカウント単位のBlock Public Accessについても確認します。

公開する必要がない環境であれば、

  • Account単位のBlock Public Access
  • Bucket単位のBlock Public Access
  • Bucket Policy
  • ACL

を確認し、意図しないPublic Accessが許可されていない状態にします。

8. 保存データを暗号化する

保存データについては、サービスごとに確認します。

S3を確認する

S3では、

  • S3
  • Buckets
  • 対象Bucket
  • Properties
  • Default encryption

を確認します。

EBSを確認する

EC2から対象のEBS Volumeを開き、Encryptionの状態を確認します。

RDSを確認する

RDSから対象のDatabaseを開き、StorageのEncryption設定を確認します。

重要なのは、

「AWSで暗号化しているからOK」

だけで終わらせないことです。

KMSを利用している場合は、

  • どのKMS Keyを利用しているのか
  • 誰がそのKeyを利用できるのか
  • 誰がKey Policyを変更できるのか

も確認します。

Terraformで管理している場合は、各リソースの暗号化設定やKMS Keyの指定をコード側で確認します。

9. HTTPSを利用する

Webサービスでは通信がHTTPSになっているか確認します。

ALBを利用している場合

AWSマネジメントコンソールから、

  • EC2
  • Load Balancers
  • 対象ALB
  • Listeners and rules

を確認します。

HTTPSの443 Listenerが存在するか確認します。

次にACMを開き、

  • 証明書が有効か
  • 対象ドメインが正しいか
  • ALBで利用されているか

を確認します。

HTTPの80 Listenerを利用している場合は、必要に応じてHTTPSへRedirectする設定にします。

10. GuardDutyで不審な挙動を確認する

GuardDutyを利用している場合はFindingを確認します。

AWSマネジメントコンソールで確認する

AWSマネジメントコンソールから、

  • GuardDuty
  • Findings

を開きます。

Findingが存在する場合は、

  • Severity
  • Finding type
  • 対象リソース
  • IPアドレス
  • 発生日時

などを確認します。

例えばIAMの認証情報に関係するFindingであれば、

  • 対象のIAM UserやRoleを確認する
  • CloudTrailで関連操作を確認する
  • 不要なアクセスキーを無効化する
  • 必要に応じて権限を停止する

といった対応につなげます。

11. Amazon Inspectorで脆弱性を確認する

Amazon Inspectorを利用している場合は、Findingsを確認します。

AWSマネジメントコンソールで確認する

AWSマネジメントコンソールからAmazon Inspectorを開き、Findingsを確認します。

まず、

  • Critical
  • High

など重要度の高いFindingから確認します。

Findingを開くと、

  • 対象リソース
  • CVE
  • 対象パッケージ
  • 現在のバージョン
  • 修正版の情報

などを確認できます。

その情報をもとに、

  • OSパッケージをアップデートする
  • コンテナイメージを作り直す
  • ライブラリを更新する

などの対応を行います。

修正後はFindingが解消されたか再確認します。

12. Security Hubでセキュリティ状況を確認する

Security Hubを利用している場合は、複数のセキュリティ情報をまとめて確認できます。

AWSマネジメントコンソールで確認する

AWSマネジメントコンソールからSecurity Hubを開きます。

主に、

  • Findings
  • Security standards
  • Controls

などを確認します。

例えばCriticalやHighのFindingが残っていれば、対象リソースと内容を確認します。

Security standardsでは、

  • MFA
  • S3
  • IAM
  • CloudTrail
  • ネットワーク設定

などについて、セキュリティチェックで問題が出ていないか確認できます。

13. 検知した問題を通知する

GuardDutyやSecurity Hubで問題を検知しても、担当者が気付かなければ対応できません。

そのため、検知するだけではなく通知まで設定します。

例えば、

  • GuardDutyでFindingが発生
  • EventBridgeでイベントを取得
  • SNSへ送信
  • メールやその他の通知先へ通知

といった構成を作ります。

AWSマネジメントコンソールでは、

  • EventBridge
  • Rules

からルールを作成します。

通知したいイベントを指定し、TargetとしてSNSなどを設定します。

Terraformで運用している場合は、

  • EventBridge Rule
  • EventBridge Target
  • SNS Topic
  • SNS Subscription

などもTerraformで管理できます。

14. 定期的に見直す

ここまで設定しても、AWS環境は時間とともに変化します。

新しいユーザーやRoleが追加されたり、Security Groupが変更されたり、新しい脆弱性が発見されたりするためです。

そのため定期的に、

  • IAMのユーザー・ロール・権限
  • IAM Identity Centerの割り当て
  • アクセスキー
  • Security Group
  • S3の公開設定
  • InspectorのFinding
  • GuardDutyのFinding
  • Security HubのFinding

などを確認します。

例えば月に一度、

  1. 不要なIAMユーザーやIAM Identity Centerの割り当てがないか確認
  2. 長期間利用されていないアクセスキーを確認
  3. 0.0.0.0/0や::/0のSecurity Groupを確認
  4. PublicなS3 Bucketを確認
  5. Critical / Highの脆弱性を確認
  6. 未対応のGuardDuty / Security Hub Findingを確認

といった確認を行います。

Terraformで管理している場合

Terraformを利用している環境では、

AWSコンソールで現状を確認し、変更はTerraform側へ反映する

という考え方が重要です。

例えばSecurity Groupに問題が見つかった場合、AWSコンソールから直接Inbound ruleを削除すると、その場では問題を解消できます。

しかしTerraform側のコードが変更されていなければ、

Terraform上の設定とAWS上の設定が違う

という状態になります。

そのため基本的には、

  1. AWSコンソールで現在の状態を確認する
  2. Terraformの対象コードを確認する
  3. Terraform側を修正する
  4. terraform planで変更内容を確認する
  5. terraform applyでAWSへ反映する

という流れで対応します。

ただし、実際にインシデントが発生していて緊急対応が必要な場合は、先にAWS側で影響を止め、その後Terraformへ変更を反映することもあります。

まとめ

AWSのセキュリティ対策では、「IAMを最小権限にしましょう」「CloudTrailを有効にしましょう」と考えるだけでは、実際の作業にはつながりません。

まず、

認証・権限 → 記録 → 公開範囲 → データ保護 → 検知 → 全体確認 → 通知

という流れでAWS環境を確認します。

AWSマネジメントコンソールでは、

  • IAM / IAM Identity Center → 誰がどんな権限を持っているか
  • CloudTrail → AWS上の操作を追跡できるか
  • Security Group → 何がインターネットへ公開されているか
  • S3 → Publicになっていないか
  • S3 / EBS / RDS → 保存データが暗号化されているか
  • ALB / ACM → HTTPSで通信できているか
  • GuardDuty → 不審な挙動が検出されていないか
  • Inspector → 未対応の脆弱性がないか
  • Security Hub → セキュリティ上の問題が残っていないか

を実際に確認します。

そして問題が見つかったら修正し、Terraformで管理しているものについてはTerraform側にも反映します。

さらに、GuardDutyやSecurity Hubなどで問題を検知した場合に、担当者へ通知して対応できる状態まで作ります。

一度設定して終わりではなく、権限や公開設定、脆弱性、Findingなどを定期的に見直すことも必要です。

「何を設定するか」だけではなく、「どこで確認し、問題があったらどう直すか」
「その後どう検知して対応するか」まで決めることが、
実際のAWSセキュリティ運用では重要です。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?