AWSでマルチアカウント管理を考える
（SCPでガードレールを作ろう②）

投稿日: 2023/7/17

はじめに

こんにちは、園田です。
本記事は、「AWSでマルチアカウント管理を考える（SCPでガードレールを作ろう②）」となります。

過去の記事はこちら

AWSでマルチアカウント管理を考える（SCPでガードレールを作ろう②）

Security Hubの内容からガードレールを考える

Security Hubの「重要」のチェック項目については、AWSドキュメントに「この問題は、さらに悪化しないように直ちに修復する必要があります。」と記載があります。

そのため、「セキュリティリスクがある状態にしない（操作を防止する）」というのが可能かどうかについて検討を実施しましょう。

例としてS3の重要項目「S3 バケットはパブリック読み取りアクセスを禁止する必要があります」について考えてみましょう。
S3のパブリックアクセスについては「意図せず公開状態としてしまい、情報漏洩が発生する」ケースが過去発生したことから、そのような事象が発生しないよう「ブロックパブリックアクセス (バケット設定)」というものが設定できるようになりました。（現在ではバケット作成時、デフォルトで有効となっています。）

S3のパブリック読み取りアクセスを許可するためには「ブロックパブリックアクセス」を無効化し、且S3のバケットポリシーでパブリックアクセスを許可する必要があります。
そのため、「ブロックパブリックアクセス」を無効化しない限り、パブリックアクセスを設定することはできません。

という訳で、「ブロックパブリックアクセス」を無効化できないようなSCPの設定を考えてみましょう。「ブロックパブリックアクセス」を無効化については「s3:PutBucketPublicAccessBlock」のAPIとなります。そのため、本APIをDenyしてしまえばOKとなります。

「ブロックパブリックアクセス」を無効化のSCP Policy：

            {
                "Version": "2012-10-17",
                "Statement": [
                    {
                        "Effect": "Deny",
                        "Action": [
                            "s3:PutBucketPublicAccessBlock"
                        ],
                        "Resource": "arn:aws:s3:::*"
                    }
                ]
            }
            
        

ただ、この場合、すべてのユーザがブロックパブリックアクセスを無効化できません。
特別な事情からS3バケットを公開する必要があるケースも考えられます。そのため、特定のユーザ、またはロールからのみ操作を許可するという対応が必要です。

この場合、特定のロール、またはIAMユーザについては利用者からの申請を受け、バケットの公開が必要であると判断できる必要があります。併せて申請手順や、申請理由を記載するフローを整える必要があります。
なお、IAMユーザの場合、管理者が変更になってしまう可能性があるため、基本的にはロールでの運用とした方が良いです。（IAMユーザからスイッチさせる。フェデレーションを実施する。など）

特定ユーザや、特定ロールを除外するのは「Condition」の「StringNotLike」で定義することが可能です。（通常はDenyされるが、StringNotLikeの文字列に合致する場合はDenyが除外される）

「ブロックパブリックアクセス」を無効化のSCP Policy（特定のユーザ、およびロールを除外）：

            {
                "Version": "2012-10-17",
                "Statement": [
                    {
                        "Effect": "Deny",
                        "Action": [
                            "s3:PutBucketPublicAccessBlock"
                        ],
                        "Resource": "arn:aws:s3:::*",
                        "Condition": {
                            "StringNotLike": {
                                "aws:PrincipalARN": [
                                    "arn:aws:iam::*:user/admin-user"
                                    "arn:aws:iam::*:role/admin-role"
                                ]
                            }
                        }
                    }
                ]
            }
            
        

この設定の場合、「"arn:aws:iam::*:」の後の文字列が「user」の場合はIAMユーザ、「role」の場合はIAMロールとなります。記載の通り、IAMユーザとIAMロールは混在して記載が可能です。

という形で、「「S3バケットはパブリック読み取りアクセスを禁止」というガードレール（SCP）を作成することが出来ました。当たり前ですが、AWSの標準では利用者のルールや運用は考慮してくれないため、きちんとその辺を考慮したうえで定義を行う必要があります。

予防的ガードレールを適用できないもの

Security Hubのアラート項目をすべてガードレールに実施出来れば良いのですが、実際にはそのようにすることは難しいです。再度Security Hubの重要の項目を見てみましょう。
（Security Hubの重要の項目は2023年6月時点のものとなります。常にチェック項目はアップデートされますので、最新版をダウンロードしてください。）

Security Hubでの「重要」のチェック項目

「セキュリティグループは、リスクが高いポートへの無制限アクセスを許可してはなりません。」という項目があります。この場合、セキュリティグループの設定に「0.0.0.0/0」が入っているという事になりますが、ガードレールはあくまでAPIとなるため、中身をチェックするという事は出来ません。

そのため、セキュリティグループの設定変更を禁止するという形になるかと思います。その場合、APIとしては以下が該当します。

セキュリティグループの変更を禁止する際に必要なAPI

• AuthorizeSecurityGroupIngress:
  インバウンドルールを追加
• AuthorizeSecurityGroupEgress:
  アウトバウンドルールを追加
• RevokeSecurityGroupIngress:
  インバウンドルールを削除
• RevokeSecurityGroupEgress:
  アウトバウンドルールを削除
• ModifySecurityGroupRules:
  セキュリティグループルールを変更
• CreateSecurityGroup:
  セキュリティグループを作成
• DeleteSecurityGroup:
  セキュリティグループを削除

見ていただければわかりますが、これらのAPIを禁止してしまった場合、クラウドの特徴であるアジリティが損なわれてしまいます。そのため、「セキュリティグループは、リスクが高いポートへの無制限アクセスを許可してはなりません。」については、SCPによるガードレールを設けるというより、Security Hubにて検知を行い、アラートが上がった際に確認・修正するという運用を実施したほうが良いと考えます。

security Hubにてガードレールとして設定できそうなもの

Security Hubのアラートの「重要」項目からガードレールとして実施できるものについては基本以下の通りになるかと思います。

• IAM ルートユーザーアクセスキーは存在してはなりません
• EBS スナップショットはパブリックに復元可能ではありません
• RDS スナップショットはプライベートにする必要があります
• SSM ドキュメントは公開できません
• S3 バケットはパブリック書き込みアクセスを禁止する必要があります
• S3 バケットはパブリック読み取りアクセスを禁止する必要があります

全部記載すると量が多くなってしまいますので、「EBS スナップショットはパブリックに復元可能ではありません」について記載したいと思います。

EBSのスナップショットですが、EBSの「スナップショット」を選択し、「アクセス許可」のタブから「アクセス権限を変更」をクリックすることで変更可能です。

「アクセス権限の変更」をクリックすると以下のような画面に遷移しますので、「パブリック」にチェックを入れ、「設定を保存」することでパブリックに公開することが可能です。

このような操作はそもそも実施する必要がありませんので、ガードレール（SCP）にて禁止にしてみましょう。

「EBSスナップショット」のパブリック公開を無効化：

            {
                "Version": "2012-10-17",
                "Statement": [
                {
                    "Sid": "DenyActionsPublicEbsSnapshotSharing",
                    "Effect": "Deny",
                    "Action": [
                        "ec2:ModifySnapshotAttribute"
                    ],
                    "Resource": "*",
                    "Condition": {
                        "StringEquals": {
                            "ec2:Add/group": "all"
                        }
                    }
                }
            }
        

S3に関しては特定のユーザやロールのみ除外の設定を実施しましたが、「EBSスナップショット」のパブリック公開を無効化についてはパブリック公開のみを制限できるため、特に除外設定は加えていません。

※Conditionの条件キーとしてec2:Add/groupがallのみとすることで、「パブリック公開のみの制限」に絞っています。（条件キーの値が「all」である場合、パブリックを表します。特定のアカウントに公開する際はアカウントIDが入るため、制限に引っ掛かりません。）

ガードレールの設定は適時アップデートしよう

今回はSecurity Hubでのチェック項目からガードレールの設定を考えてみました。
これ以外にもIAMのベストプラクティスや、実際の運用を実施していく中でこの操作については禁止したほうが良いかな。というのが出てくるかと思います。

SCPはあくまでAPIの禁止となるため、すべてが思い通りになるわけではありませんが、運用ルールとセットと考えることで、企業にあったセキュリティ強化を実施できると考えています。

ルールで禁止というのはどうしても穴が出来てしまいますので、管理者の方は積極的にSCPの機能を使ってクラウドを安全に利用が出来るよう頑張ってほしいと思います。

次回はセキュリティ許可のためのSecurity Hubの導入と運用について記載したいと思います。
では、また次の記事でお会いしましょう。

CTCは、AWSのビジネス利活用に向けて、お客様のステージに合わせた幅広い構築・運用支援サービスを提供しています。
経験豊富なエンジニアが、ワンストップかつ柔軟にご支援します。
ぜひ、お気軽にお問い合わせください。