オンプレミスシステムのクラウドリフトにおいてBLEAを利用してセキュリティのベースラインを確保した話

はじめに

RejectDay2023で発表させていただいたないようをブログにまとめていきます。
とあるオンプレミスで実装されていたシステムをクラウドリフトした際に、BLEA(Baseline Environment on AWS)を利用して、セキュリティのベースラインを効率的に確保した事例を紹介します。
BLEAとは何か？、CloudFormationで構成されたシステムにも利用できるのか、カスタマイズ要素はあるのか、使ってみてどうだったのかなどのポイントを解説します。
※サーバ構成やNW構成やアプリケーション側のセキュリティ対策等に関することは触れません。

概要

プライベートクラウド上で動作する１システムをAWS　Organizationsで管理されたAWS上にクラウドリフトしました。もともと、プライベートクラウド上では、中央集権的な管理が行われており、ログの管理や、基盤上のセキュリティ、NW上の脅威検知など基礎的なセキュリティ対策が行われていましたが、移行先のAWS環境では、アカウントと、証跡（CloudTrail、Configのみ）管理飲みが実装された状態で、その他は利用者の責任でセキュリティ対策の実施が必要な状態でした。また、利用する環境はSCPで権限がコントロールされており、利用できる権限が制限された状況でした。

課題

概要に記載した通り、クラウド上でのセキュリティ対策を自身で検討する必要がある→AWS環境において、必要とされるセキュリティ対策を実装する必要がありました。とはいえ、楽に実装したいとの考えでどのようなものが利用できるかを検討しました。

実施したこと

BLEAを利用して、AWSアカウント上のベースラインとなるセキュリティ対策を実装しました。
また、VPC内のリソースはすでに実装済みであった、CloudFormationを利用し、CDKとの併用を行いました。

BLEAとは

BLEA: Base Line Environment on AWS
AWSのセキュリティのベストプラクティスを実装した環境を、迅速に実現するためのテンプレート（CDK）

AWSのサービスは Security by Design の考えに基づいて実装されていますが、お客様は、システム構築にあたってこれらのサービスを組み合わせ、要件に合わせてコンフィグレーションする必要があります。AWS では AWS Well-Architected や AWS Security Reference Architecture (AWS SRA)といったセキュリティのベストプラクティスをドキュメントとして提供しており、この中では AWS CloudTrail 有効化による API 呼び出しの記録など、どのようなシステムでも最低限実施いただきたい基本的な設定をガイドしています。この基本的な設定をベースラインと呼びます。ベースラインはどのシステムでも共通に実施すべき内容であり、これをテンプレートによって自動構築することで、作業漏れおよびミスの混入防止、作業工数の削減ができ、基本的なセキュリティを確保することができます。

つまり、AWSのベストプラクティスに基づいて作られている、最低限実装すべき設定が実装された素晴らしいテンプレート郡ということです。これを使えば、最低限の設定かつベスプラが即実装できるのです。
通常セキュリティ対策は、AWSのサービスを選定し、個別に設計を行い、どのような監視や検知を行うかなど詳細に検討、設計、実装を行っていました。BLEAを使えば、その検討や設計を大幅に短縮でき、とりあえずBLEAで実装、個別の要件についてのみ追加の検討を行えばよいので、かなり楽になります。

BLEAで提供されるテンプレート

以下２つの利用パターンがあります。
複数アカウントであれば、マルチアカウント版ですが、今回はすでにOrganizationsによって管理されていた１アカウントに実装したかったため、シングルアカウント版を利用しています。お気軽に１システムで利用する場合は、シングルアカウント版を使うのが良いでしょう。
以下の図のように、大きくゲストシステムのガバナンスベースと別れており、ゲストシステムはWebアプリケーションのサンプルがCDKで実装されています。ガバナンスベースでは、CloudTrailをはじめ各種セキュリティ関連のサービスが実装されたテンプレートが提供されます。
※引用：https://aws.amazon.com/jp/blogs/news/announcing-baseline-environment-on-aws/

CDKとCloudFormation

そもそも、CDKとCloudFormationの違いを理解しないとBLEAを使いこなすことが困難です。
まず、CloudFormationですが、こちらはJSON,YAML形式で記載するテンプレートであり、詳細に設定を記載する必要があるものです。対してCDKはプログラミング言語ベースでコードを記載、リソースのプロビジョニングが可能です。また、AWS推奨値がデフォルト設定で実装されるため、最小限のコード記載で、自動で設定が行われます。基本的にCDKを使えるなら使ったほうが効率、セキュリティともによいですね。

BLEAを利用する上で覚えておいたほうが良い知識

まずは、CDKのプロジェクト構成を覚えましょう。
①App　：Stackを定義する。複数Stackを定義することも可能である。
②Stack：リソースを定義する。 Cloud FormationのStackと同義である。
③Construct： Stack内で記述するAWSサービスが定義されたライブラリ。

また、CDKのコンストラクタの種類も覚えておきましよう。基本L2を使っておけば問題なしです。
コンストラクタの種類コンストラクタにはL1～L3があり、大きな違いは以下のとおり。基本的にL2を使うことが多い。
L1コンストラクト：CFｎのすべてのプロパティと１対１で対応している。
L2コンストラクト：基本的に細かいプロパティは設定が不要である。
L3コンストラクト：複数リソースをまとめて定義できる。（AWSが事前定義）

最近BlackBeltでCDKの概要解説があり、非常にわかりやすかったので、そちらを見ると良いでしょう。

CDKとCloudFormationの併用

今回はCloudFormationとの併用を行いました。理由としてはすでにテンプレートがあり、CDKでの開発をすることに時間をさきたくなかったためです。とはいえ、以下の工夫を行いました。
・相互参照するリソースはできる限り避ける（KMSやSNSなど相互参照したほうが効率が良いものがあるが、CDKとCFｎで別々に定義した）
また、当時はCDKｖ１でしたが、現在ではｖ２が提供されており、CloudFormationテンプレートのCDKテンプレートへのインクルード、CFｎスタックのCDKへの移行などがサポートされています。こちらもCDKへの移行として検討するのが良いでしょう。

BLEAベースラインテンプレートにより実装される内容

以下が実装されます。特に検知条件の設定が一押しです。
通常、CloudTrailなどの検知キーワードなどは、検討の上、監視文字列を様々なノウハウ、ベスプラ、などから育てた上で、設定していくものですが、BLEAを利用すれば、一発でベスべスプラに基づいた検知キーワードの設定がされます。

カスタマイズ要素

今回BLEAのデフォルト設定からいくつかのカスタマイズを行いましたのでご紹介します。

問題1 EventBridgeルールで検知した情報をSNSでメール通知する際に文面が見づらい

解決策として、テンプレート内でインプットトランスフォーマーを定義し、通知を見やすく整形しました。

問題２　CloudTrailの取得対象が管理イベントのみ　(S3やDynamoDB、Lambdaのデータイベントも取得したい)

解決策として、データイベント、インサイトイベントも追加するようにテンプレートをカスタマイズしました。

問題3 GuardDutyの脅威検出結果の配信先バケット、配信時に使用するKMSキーがない

もともと、GuardDutyの配信設定にはCDKが対応していないため、手動で対応しました。
配信先のS3バケット、暗号化用のKMSのみテンプレートに追加定義を行いました。

問題４　Configの配信設定でKMSを利用しない方式となっている

基本的にS3のログはKMSで暗号化しておきたいため、KMSを利用するようテンプレートを修正しました。

問題5 大阪リージョンへのBLEAデプロイにおいて、Condiｇの一部設定が対応されていない

BLEAでは今フォーマンスパックを利用した設定を行うことになっているが、大阪リージョンに対応できないものが一部存在していました。そのため、コンフォーマンスパックの内容をデプロイするリージョンごとに変更、選択するロジックをテンプレートに設定しました。

問題6 スタック間の依存関係が設定されている場合、デプロイ時に指定しなくても依存関係のあるスタックをデプロイしてしまう

今回は、BLEAの一部テンプレートをデプロイしたくないという事情があった（Organizations側で設定が行われているリソースがあったため）ため、Appテンプレートでデプロイ内容のカスタマイズを行いました。

問題7 命名規約がPJで定めたものと異なる

通常どのPJでも命名規約を定めると思うのですが、当然ながらBLEAで生成したリソースはその命名規約には従いません。そのため、命名規約に従うようテンプレートをカスタマイズしました。とはいえ、これは反省ですが、本質的にやっても効果がないことに時間をかけるべきではなかったかなと思っています。名前を変更することにあまり意味はないため、無駄に時間をかけないほうがよいです。

まとめ

BLEAを導入したことで以下の様な効果がありました。
BLEAを利用するとAWSを利用する上で効率的にセキュリティのベースラインの確保をすることができます。
AWSアカウントは利用しているけど、どんな対策をしたらいいんだろう？対策はわかるけど手間だな、対策は実施しているけど足りているのだろうか？そんな場合に最適です。
CloudFormationで開発している、請求代行などでSCPによって権限が絞られている、開発環境・・・etc
たいていの場合利用可能です。
ベースラインテンプレートを流す上での前提条件はシンプルなので、是非利用を検討してみてください。

１．監視すべきCloudTrailのログのキーワードやイベントなどが定義されているので、設計が楽になる

２．ベストプラクティスに基づき一般的に実施すべきベースラインが実装されるので、セキュリティが効率的に確保できる作業漏れ、検討漏れがなくなる

３．テンプレートの構成が理解しやすくカスタマイズがしやすい→テンプレートの複雑化や、１からコーディングする必要がない

４．今後CDKを利用する上でのお手本構成を学習できる