選択肢に加えたいAWSのセキュリティベスプラ3選
「昨日までの正解が、今日も正解とは限らない。」AWSを面白いと感じる個人的な理由はこれです。一方で、日頃Well-Architected Framework Review (WAFR) をはじめとして、業種や規模、状況も多種多様なワークロードをレビューさせていただく中で、進化が早くてAWSツライという方もたくさんお見かけします。またエンプラの現場は「寝た子を起こすな」ではないですが、動いているものを変更することに慎重なことも多く、新しい選択肢が採用に至るまでに時間を要することも少なくありません。
多くのワークロードには経緯や事情があり正解はひとつではありませんが、キャッチアップが追いつかないという方や、まだ様子見中という方にも選択肢に入れて欲しいベスプラを3つ整理してみました。（毎回説明するのが面倒でコレ見てと言いたかっただけともいう）
1. パブリックサブネット廃止
W-A Frameworkでいうと、セキュリティピラーの「インフラストラクチャの保護」というベストプラクティス領域と関連します。SEC05とSEC06のいずれも「外部および内部ネットワークベースの脅威」への言及がありますが、パブリックサブネットはSEC05-BP01でいうアクセス要件に応じたネットワークレイヤーのひとつです。
1.1 CloudFront VPC Origins
これまで左のようなアーキテクチャ図を何度目にしてきたか分かりませんが、2024年11月のアップデートによって、CloudFrontディストリビューションのオリジンに、プライベートサブネット内の Application Load Balancer (ALB)、 Network Load Balancer (NLB)、または EC2インスタンスを選択できるようになりました。これを使用すると右図のように、ALBを配置するためのパブリックサブネットが必要なくなり、アタックサーフェスとなり得るネットワークレイヤーを減らすことができます。パブリックなIPv4アドレスも不要になるので、コスト削減も期待できます。2025年11月にはクロスアカウントもサポートされ、異なるAWSアカウントにあるVPC オリジンにもアクセスできるようになりました。
ネットワークの変更となると二の足を踏みがちですし、CloudFrontの料金プラン（Business以上の定額制プラン or Pay-as-you-go）や利用可能なプロトコル等、いくつか条件がありますが、是非取り入れてほしいと思うパターンです。
1.2 Regional NAT Gateway
こちらはなぜ今までなかったのかと思う機能ですが突然登場しました。従来のZonalなNAT Gatewayでは、サブネットが多いとNAT Gatewayへのルートの管理もバカにならず頭の痛い問題でしたが、RegionalなNAT Gatewayの登場によって一気にシンプルになりました。
これだけでもとても素晴らしいアップデートですが、今回注目したいのはRegional NAT Gatewayはパブリックサブネットが不要（Internet Gateway自体は必要）である点です。Egress専用VPCを作ってNAT Gatewayを共有している等でなければ、従来のZonal NAT Gatewayを選ぶ理由はあまりないと思うので、是非活用してほしいです。AWSもプライベートなNAT以外ではRegional NAT Gatewayの利用を推奨しています。
コストはZonal NAT Gatewayを各AZに配置する場合と同等ですが、Regionalの方が使用できるIPアドレスの数が多いので使い方によってはその分のコストがかかります。IPアドレスは自動（リクエスト量に応じて自動で増減）もしくは手動で管理可能です。接続元のIPアドレスをホワイトリスト登録してアクセス制御をしているようなケースや、コストを細かく制御したい場合は、手動での管理が良いと思います。
1.3 Egress-Only Internet Gateway
IPv6が利用可能でNATが必要がない場合やNAT64したくない場合は、Egress-Only Internet Gateway (IGW) の利用を検討すると良いかもしれません。
パブリックサブネットの廃止と言っておきながら、「Egress-Only Internet Gatewayへのルートを持つサブネットはパブリックサブネットだろ！」ってツッコミを受けそうですが、一応言い訳しておくと、パブリックサブネットの定義は人によって微妙に異なることが多いです。AWSがユーザガイドに記載しているのは、
サブネットに関連付けられているルートテーブルにインターネットゲートウェイへのルートがある場合、そのサブネットは「パブリックサブネット」と呼ばれます。
で、これにはEgress-OnlyなIGWへのルートは含まないと考えればどうでしょう？
パブリックサブネットの廃止を勧める理由は、インスタンス等のリソースが外部からアクセスできる状態になり得るサブネットを無くすことにあるので、「パブリック」や「プライベート」といったラベルは本質ではありません。
IPv4アドレスの利用料もかからないし、もしかしたら実はあなたのワークロードはRegional NAT Gatewayすら必要としていないのかもしれませんよ。
2. AWS Loginの利用
W-A Frameworkでいうと、セキュリティピラーの「Identity and Access Management」というベストプラクティス領域と関連します。SEC03-BP01には「永続的な認証情報を使用する」のはアンチパターンだとはっきり書かれています。また、IAMのユーザガイドにも「長期的なアクセスキーに対する代替方法を検討せよ」と書かれています。
可能であれば、IAM Identity Centerを使用するのが統制の面からも良いと思います。しかし、組織内の管理体制や業務委託に伴う制限等でIAM Identity Centerが利用できない場合や、割引率等の事情でリセラーからSPAM (Solution Provider Account Model) でアカウントを調達されていてIAM Identity Centerの利用が現実的でない場合等、現実には止む無くIAMユーザが使用されているケースは多くあります。
そんな状況もついに終わる日が来ました。aws loginコマンドを利用すれば、一時的なクレデンシャルを利用してCLI等からAPIにアクセスできます。今すぐアクセスキーを無効化しましょう！
なお、aws loginコマンドの利用には、SignInLocalDevelopmentAccessマネージドポリシー相当の権限が必要なのと、プロファイルの取り違えと同様、ログインするアカウントの取り違えには注意しましょう。
3. IAM Policy Autopilotの活用
これもW-A Frameworkでいうと、セキュリティピラーの「Identity and Access Management」というベストプラクティス領域と関連します。SEC03-BP02は主に人間によるアクセスを念頭に置いているようにも見えますが、PoLPの必要性について述べており、SEC03-BP04はアクセス許可を継続的に削減していくことを推奨しています。IAMのユーザガイドでも同様に「最小特権アクセス許可を適用する」、「AWS 管理ポリシーの使用を開始し、最小特権のアクセス許可に移行する」ことがベストプラクティスとされています。
さて、PoLPが大事なことは分かるけど実際どこまでやれるかとなると別の話で、ざっくり設定しているということも多いように思います。特に人間向けは頑張って設定していても、アプリケーションのコード毎にやるのは大変ですよね。
IAM Policy Autopilotを使えば、そんな状況を少し改善することができるかもしれません。
現時点でサポートされているのはPython・TypeScript・Goだけのようですが、 食わせたコードを分析して、さくっとIAMポリシーを出力してくれます。軽く試した感じ、厳密に必要な最小権限に削ってるわけではなさそうですが、最低ラインの底上げや最初の叩き台として活用できると思います。MCPサーバーとしても使えるので、Kiro等からも使えます。
番外編: Security Agent
W-A Frameworkのセキュリティピラーには「アプリケーションのセキュリティ」というベストプラクティス領域があります。なかでも「SEC11-BP03: 定期的にペンテストを実施する」のように時間と費用が大きくなりやすいものや、「SEC11-BP08: ワークロードチームにセキュリティのオーナーシップを根付かせるプログラムを構築する」のようにカルチャーに関するプラクティスを実践するのは容易ではありません。
AWSは事あるごとにセキュリティはJob Zeroであり、全員でセキュリティに取り組むカルチャーを強調しています。同社にはSecurity Guardians等のプログラムも存在し、ベスプラが実際に実践されているのだと思いますが、多くの企業にはそれを真似する十分な余力がないというのも実情です。
そんな中、AWS Security Agentが発表されました。まだPreviewですが、設計段階のレビューからオンデマンドのペネトレーションテストまで実施してくれるエージェントです。まだ評価できていませんが、組織のセキュリティカルチャーの醸成やシフトレフトの実現に役立ちそうです。近い将来、W-A Frameworkのベスプラに「AWS Security Agentを使う」と書かれる日が来るのかもしれません。あまりにできる子だったら私がいらなくなりますが、それはすばらしいことですね！
Discussion