【re:Invent 2020レポート】AWS環境を保護するための効果的な10の方法

技術2課の山﨑です。かなり出遅れましたが、現在開催中のre:Invent 2020のセッションレポートをお届けします。

はじめに

本記事はre:Invent 2020で行われた「Ten easy and effective ways to secure your AWS environment」セッションのレポートです。

reinvent.awsevents.com

セッション概要

本セッションではAWS環境を保護するための効果的な方法として以下の10の方法が紹介されていました。

f:id:swx-yamasaki:20201213112002p:plain

詳細については是非セッションをご視聴頂きたいのですが、ここでは誤解を恐れずにそれぞれの概要を超簡単に説明すると

特殊なケースを除き、S3に保存しているデータはプライベートアクセスにしましょう！
※S3作成時のデフォルト設定ではBlock Public Accessが有効になっている
AWSリソースへのアクセスにはSSOやフェデレーション、IAMロールの使用等、IAMの一時認証情報を積極的に活用しよう！
AWS Oraganizationsを使ったマルチアカウント構成を取っている場合、監査ログはCloudTrailを使って1つのアカウントで集中管理しましょう！
CloudTrailのログはAmazon Athenaを使って分析して、IAMポリシーの修正等に役立てよう！
サブネットにはその性質（PrivateやPublic）に従ってタグを付けましょう！
AWS Oraganizationsを使ったマルチアカウント構成を取っている場合、ネットワーク制御はAWS Firewall Managerを使って1つのアカウントで集中管理しましょう！
AWSリソースにアクセス可能なネットワークリソースはIAMポリシーで明示的に記載しましょう！
※当セッションではS3を例として、特定のVPCネットワークに属するリソースや特定のIP Sourceからのアクセスのみを許可するバケットポリシーを記載するといった話がありました
7と関連する内容だが、VPCエンドポイントにIAMポリシーをアタッチすることでAWS Oraganizationsのネットワーク内でも特定のOUからのアクセスのみを許可するように制御できるよ！
EC2へのアクセスにはSystems Manager Session Managerを利用しよう！
Route 53 Resolverを使って取得したDNSクエリログをCloudWatch Logs等に連携することでトラフィックパターンの分析やトラブルシューティングに役立てることができるよ！

この中で5つ目の「サブネットにはその性質（PrivateやPublic）に従ってタグを付けましょう！」の箇所が話を聞いた時にすぐにピンとこなかったので検証してみました。

検証

事前準備

サブネットにタグを付与

今回はTypeをキーとして指定し、パブリックサブネットとプライベートサブネットにそれぞれ「public」「private」という値を付与しました。

IAMポリシーの作成とアタッチ

以下のようにカスタムポリシーを作成して、IAMユーザーにアタッチします。これでサブネットに付与されたタグのTypeキーの値がprivateでない場合はEC2の操作を明示的に拒否しています。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": "ec2:*",
            "Resource": "arn:aws:ec2:*:*:subnet/*",
            "Condition": {
                "StringNotEqualsIfExists": {
                    "aws:ResourceTag/Type": "private"
                }
            }
        }
    ]
}

EC2作成

コンソール画面よりパブリックサブネットとプライベートサブネットにそれぞれEC2を構築しようとすると以下のような結果となりました。

パブリックサブネット（Type:public）

f:id:swx-yamasaki:20201213143636p:plain

プライベートサブネット（Type:private）

f:id:swx-yamasaki:20201213143650p:plain

これにより、ある特定のIAMユーザーあるいはIAMグループに対してEC2の操作をタグベースでコントロール可能であることが分かりました。
本セッションでは、AWS Oraganizationsのマルチアカウント構成を具体例として挙げていました。
マルチアカウント構成の場合、管理アカウントからCloudFormation Stack Setを使って別アカウントに対してリソースを構築することが可能なためユーザーが誤ったサブネットにEC2リソースを構築しないようにするためにタグベースでアクセス管理することを勧めているのかなと思いました。
とはいえタグベースのアクセス管理はEC2以外のリソースに対しても応用が効くので、EC2に限らず様々なシーンで活用できそうです。