シフトレフトを意識してAWS環境を設計・構築しよう!

こんにちは！クラウド事業本部の吉田です。

「セキュリティ対策は後回し」「とりあえず動くように作ってから後で直そう」
そんな考えでAWS環境を設計・構築し、後になってAWS Security Hubでセキュリティ問題が大量に検出されて慌てた経験はありませんか？

今回は、シフトレフトを意識してAWS環境を設計・構築することで、後々のコストや手間を大幅に削減する方法をまとめてみました。

まとめ

• シフトレフトとは、システム開発の上流工程でセキュリティ対策を組み込むアプローチ
• AWS環境でも設計段階でセキュリティを考慮することで、後からの対応コストを大幅に削減できる
• 具体的な対策として以下が有効
  • AWSガイドライン作成：全社的に従うべき設計指針を明文化
  • IaCの活用：AWS Service CatalogやHCP Terraformを利用し、セキュリティが担保された環境を構築
  • 組織的なセキュリティ統制：AWS Organization SCPによる予防的ガードレールやAWS Security Hub自動修復ソリューションを設定

シフトレフトとは

シフトレフトとは、システム開発の上流工程でセキュリティ対策を組み込むアプローチを指します。
どちらかというとソフトウェア開発で使われる概念ですが、インフラ(AWS環境)の設計においても重要な考え方です。

「まず動くものを作ってから後でセキュリティを考える」というアプローチを取ることが多いと思いますが、これでは以下の問題が発生します。

• 後から対応すると工数が倍以上かかることがある
• システム停止を伴う大規模な改修が必要になる
• セキュリティリスクにさらされる期間が長くなる

「PoC環境だったら、セキュリティをそこまで意識する必要ないんじゃない？」と思われる方がいるかもしれません。
ただお聞きしたいのですが、ワークロード環境を構築する際、PoC環境から設定・構成を変更して構築しますか？
インフラ環境に関しては動作実績があるPoC環境の設定・構成を踏襲することが多いのではないでしょうか？
ちなみに私は、PoC環境がそのまま本番環境になってしまったという恐ろしい経験があります。
PoC環境であっても最初からセキュリティを意識することはとても重要なことです。

AWS環境設計・構築におけるシフトレフトの重要性

AWS環境設計・構築でシフトレフトを意識しないとどのような問題が発生するのか、具体例を見てみましょう。

よくあるケースとして、「サービスリリース後に、パブリックサブネットにあるEC2をプライベートサブネットに移行する」というケースがあります。
過去にEC2をプライベートサブネットに移行した際のアクセスを整理したブログを執筆しましたので、そちらのブログから画像を引用します。

before

after

画像引用元：EC2をプライベートサブネットに移行した際のアクセス整理（インバウンド・アウトバウンド） | DevelopersIO

プライベートサブネット移行にあたって、主に下記の作業が発生します。

• プライベートサブネット作成
• プライベートサブネットへのEC2の移行
• ALBがなければALB追加
• NAT Gateway追加
• ルートテーブル設定変更
• EC2へのログイン方法変更
  • 踏み台経由のログイン
  • SSM Session Managerによるログイン
• アプリデプロイの見直し
• セキュリティグループ見直し

プライベートサブネットへの移行作業の解説は、ぜひ私の過去のブログを参照してください。
EC2のプライベートサブネット移行手順をまとめてみた | DevelopersIO

色々やることがありますよね？大変ですよね？
ここで一番問題がある点は、プライベートサブネットに移行をするにはEC2を再作成する必要があり、再作成に伴うサービス停止が発生する点です。
サービス停止するとなったら気軽に着手できるものではありません。
リスクを低減するために、主に下記の点を意識して動いていく必要があります。

• 検証環境での事前確認
• 本番作業手順・コンティンジェンシープランの整備
• サービス停止時間

最初からWeb3層アーキテクチャで設計・構築していれば、これらの手間は一切かかりません。

根本的な問題

あなたは、会社のITインフラのセキュリティを是正するセキュリティチームの一員だとしましょう。
既存のAWS環境のセキュリティを何とか是正しました。お疲れ様です！

ただ、これらのセキュリティ是正活動のことを知らない別プロジェクトの人たちがAWS環境を新規構築することになりました。
もうどうなるのかお察しですよね。

このように全社的に設計方針や対策を施さなければ、セキュリティに課題があるAWS環境を繰り返し構築される可能性が高くなり、その是正のために多大なコストをかけなければならなくなります。
AWS環境設計・構築におけるシフトレフトの重要性がお分かりいただけたのではないでしょうか。

シフトレフトを実現する3つの対策

シフトレフトを実現するには色々なアプローチがあるかと思いますが、今回は3つまとめてみました。

1. AWSガイドライン作成

全社的に従うべきAWSガイドラインを作成し、新規設計・構築時は必ず参照するようにします。
ネットワーク設計やセキュリティ対策などの章は、AWS Security Hubのコントロールを意識して執筆すると効果的です。

いきなりハードルが高いと感じられるかもしれませんが、最初から凝ったものを作る必要はありません。

以下のような初歩的な内容でも、十分効果があります。

• EC2などコンピュートリソースなどは基本的にプライベートサブネットに配置する
• Web3層アーキテクチャを意識する
• IAMロールで対応できる場合はアクセスキーを発行しない
• アクセスキーをアプリに直埋めしない
• AWS Security Hubを有効化する

またガイドライン作成には、クラスメソッドメンバーズのお客様向けに公開している「Classmethod Cloud Guidebook (CCG)」が参考になります。
CCGとは、 AWSを活用するのに役立つナレッジをまとめたWebサイトです。
ナレッジ集の1つとして、AWS利用ガイドラインのサンプルを掲載しております。
そのサンプルを元に効率的にガイドラインを作成することができます。
詳しい活用方法は下記のブログを参照してください。

クラスメソッドメンバーズのお客様向けに公開している「Classmethod Cloud Guidebook (CCG)」の使い方 #AWS 利用ガイドラインサンプルの使い方

2. IaCの活用

セキュリティガバナンスが担保された環境を構築するのにIaCが役立ちます。

AWS Service Catalogの利用

例えばPoC環境をたくさん作成する必要があるが、AWS構成は決まりきっているというケースがあるかと思います。
そのようなケースならば、AWS Service Catalogの利用を検討しましょう。
AWS Service Catalogとは、VPC・EC2 ・RDS などサービスをカタログ化するサービスです。
そのカタログ化には、CloudFormationかTerraformのテンプレートを利用します。
AWS Service Catalogを利用することで、以下のメリットを享受できます。

• ガバナンスが担保された環境が作成される
  • もちろんガバナンスが担保されたテンプレートを作成する必要があります
• 開発者などAWSに詳しくない人でも、複雑な設定を意識せずに環境構築できる
• 標準的なアーキテクチャパターンを組織全体で共有できる

AWS Service Catalogに関しては、下記の入門ブログが参考になります。
AWS 入門ブログリレー 2024 〜AWS Service Catalog編〜 | DevelopersIO

HCP Terraformでの事前チェック

HCP TerraformのAWS Security Hub用のSentinelポリシーライブラリを活用することで、AWS Security Hubのコントロールの観点で構築するリソースの内容がセキュリティ的に問題がないかデプロイ前にチェックできます。

詳細な解説は、下記の記事を参照してください。
[Terraform]AWS Security Hub 『基礎セキュリティのベストプラクティス』を満たすのに役立つSentinelポリシーライブラリが公開されました | DevelopersIO

3. 組織的なセキュリティ統制

シフトレフトから少しズレるかもしれませんが、組織的なセキュリティ統制をかけるのは有効な手段の1つです。

AWS Organization SCPによる予防的ガードレール

AWS Organization SCPを利用して、セキュリティリスクのある操作を禁止します。
一例を下記にまとめました。

• EBSの非暗号化を禁止
  • アカウントレベルでのデフォルト暗号化設定を有効化しておき、利用者による変更を防止する
• S3のSSE-C 暗号化を禁止
• 各セキュリティサービス(AWS Security HubやAWS GuardDutyなど)の無効化を禁止
• 特定のリージョン以外でのリソース作成を禁止

AWS Organization SCPは、こちらの入門ブログが参考になります。
AWS再入門2023 Organizations SCP編 | DevelopersIO

AWS Security Hub自動修復

AWS Security Hub自動修復ソリューションを活用することで、AWS Security Hubで検知された設定を自動的に修復できます。

環境に変更が加わるため、ワークロード環境に導入する際は慎重に対応する必要があります（導入当初は自動修復を有効化しないなど）が、セキュリティ運用の負荷を下げてくれるソリューションのため積極的に導入してください。

どのような設定が自動修復されるかは、下記のドキュメントを参照してください。
プレイブック - AWS での自動化されたセキュリティ対応

AWS Security Hub自動修復ソリューションの詳細に関しては、下記のドキュメントとブログをご確認ください。

• AWS での自動化されたセキュリティ対応 | AWS ソリューション | AWS ソリューションライブラリ
• バージョンアップしたSecurity Hubの自動修復ソリューション(v1.4.2)を試してみた | DevelopersIO

さいごに

AWS環境上でもシフトレフトを意識することで、セキュリティ対策の後回しによるコストや手間を大幅に削減できます。

「後で直せばいい」ではなく「最初から正しく作る」ことで、セキュアなAWS環境を構築していきましょう。

以上、クラウド事業本部の吉田でした！

参考資料

• EC2をプライベートサブネットに移行した際のアクセス整理（インバウンド・アウトバウンド） | DevelopersIO
• EC2のプライベートサブネット移行手順をまとめてみた | DevelopersIO
• クラスメソッドメンバーズのお客様向けに公開している「Classmethod Cloud Guidebook (CCG)」の使い方 | DevelopersIO
• AWS 入門ブログリレー 2024 〜AWS Service Catalog編〜 | DevelopersIO
• [Terraform]AWS Security Hub 『基礎セキュリティのベストプラクティス』を満たすのに役立つSentinelポリシーライブラリが公開されました | DevelopersIO
• AWS再入門2023 Organizations SCP編 | DevelopersIO
• プレイブック - AWS での自動化されたセキュリティ対応
• AWS での自動化されたセキュリティ対応 | AWS ソリューション | AWS ソリューションライブラリ
• バージョンアップしたSecurity Hubの自動修復ソリューション(v1.4.2)を試してみた | DevelopersIO