【第三回】
SmartKobanzaki2のAWS移行プロジェクト
～開発環境の構築～

以前のブログのおさらい

第一回ではKobanzakiの概要やAWS移行の構想、そしてAWS環境に適したセキュリティ設定を行うために利用する弊社製品のTrend Micro Cloud Oneについて記載しました。

第二回ではAWS上に移行するためのベースとなるAmazon VPCの作成やオンプレ環境との接続といったネットワークレイヤの設定、およびネットワークレイヤでのセキュリティ対策について記載しました。

本ブログ（第三回）での目標と設定実施について

・本ブログ（第三回）での設定項目

第三回の本ブログは以下を設定し、AWS上での開発環境の構築とホスト端末でのセキュリティ対策を行っていきます。

・AWS Cloud9 環境のデプロイ
・開発環境での初期セットアップ
・開発環境のセキュリティ保護の実施

・目標構成

図１：本ブログでの目標構成図

・設定の実施

<AWS Cloud9 環境のデプロイ>

開発環境は業務PCを開発に必要なモジュールやプログラムで汚さないかつGithubやAWS Secrets Manager(以下Secrets Manager)へのアクセスを簡単に制御できるという理由でAWS Cloud9(以下Cloud9)を選びました。
AWS Cloud9 とは? : https://docs.aws.amazon.com/ja_jp/cloud9/latest/user-guide/welcome.html

また、ソースコードを管理しているGitHub Enterpriseのリポジトリは社内環境でなければアクセスが出来ないため、第２回で構築した社内環境にもアクセスができるサブネットにCloud9を構築していきます。
その際、インターネットからのインバウンド通信はできない環境となるためCloud9ではAWS Systems Manager (以下SSM) による接続方式を採用しています。

Cloud9はAWSコンソール上で必要項目を一画面ポチっと選択していくだけで構築できるのでとても簡単でいいですね！

図２：Cloud9のコンソール画面

また、今回はSecrets Managerへのアクセス権を制限するためCloud9がデフォルトで使用するAWS Managed Temporary Credentials（以下AMTC）での権限管理ではなく、Cloud9インスタンスにアタッチされているIAMロールを使用しカスタマイズされたアクセス権限で運用を行うようにしています。
※Secrets Managerにアクセス制限を行っている関係で、Cloud9にアクセスするユーザに付与されるロールではなく、プロジェクト専用の特定のロールからのアクセスに制限する必要があったためとなります。

AMTCの設定はCloud9のIDEコンソールでPreferences内、AWS Settingsから変えることが出来ます。
※本設定をオフにすることで インスタンスにアタッチされたIAMロールを参照するようになります。

図３：Cloud9でのロール設定画面

・設定後の構成

図４：AWS Cloud9 環境のデプロイでの設定後の構成

<開発環境での初期セットアップ>

今回の移行プロジェクトでは開発環境がローカルのためメンバーごとに異なる可能性や、必要な設定を各自で行う必要があるという課題を解決するため準備する開発環境を開発者ごとで同一にするため、セットアップ用のスクリプトを準備し、開発環境構築時に実行することで細かい設定等を行わなくてもいいようにしています。

そのスクリプト内で社内環境のローカルマシンで使用しているコードエディターのVisual Studio Codeとの連携用設定や社内サーバとの通信を許可するためにセキュリティグループのルールアップデートを行っています。

設定の変更等は基本的にAWS CLIとEC2インスタンスメタデータ(以下IMDS)を組み合わせて実行しています。

インスタンスメタデータの取得：https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/instancedata-data-retrieval.html

なお、IMDSにはv1とv2がありv2が公式として推奨されています。
理由として、IMDSv1ではインスタンスからGETメソッドを使用したリクエストを送るだけでメタデータが取得でき、IAMロールなどの権限を取得し利用することが可能であったためSSRF(Server-Side Request Forgery)などの攻撃に悪用される可能性がありました。
そのためIMDSv2ではトークンを利用したセッション指向リクエストを使用しインスタンスメタデータへアクセスを行うことで攻撃の難易度を高め SSRFなどの脆弱性を突く攻撃を減らすことができるようになっています。
IMDSv2の使用：https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html

・設定後の構成

図５：開発環境での初期セットアップでの設定後の構成図

開発環境のセキュリティ保護の実施

本環境のネットワークレイヤでのセキュリティ保護は第２回のブログでCloud One – Network Securityで行っていますが多層防御の観点やホスト上で動作するマルウェアからの影響を対策するため Cloud9 上にもホスト型のセキュリティ製品を導入します。

Cloud One – Workload Security(以下C1WS)は物理サーバ、仮想サーバ、クラウドサーバすべてに高度なサーバセキュリティを提供します。企業のアプリケーションやデータを保護し、緊急でのパッチ適用を必要とすることなくデータ漏えいやビジネスの中断を防ぎます。
この包括的な中央管理プラットフォームにより、セキュリティに関する処理を簡素化すると同時に、仮想化およびクラウドプロジェクトのROIを向上できます。
https://cloudone.trendmicro.com/docs/workload-security/getting-started/

C1WSでは以下のセキュリティ保護を提供することでホスト型での多層防御を実現する製品となっています。

・不正プログラム対策
・ファイアウォール
・デバイスコントロール
・アプリケーションコントロール
・侵入防御 （デスクトップOS）
・侵入防御 （サーバアプリケーション）
・変更監視
・セキュリティログ監視
・コンテナの保護
https://cloudone.trendmicro.com/docs/jp/workload-security/protection-modules/

図６：C1WSのコンソール画面

C1WSの導入方法としては複数の方法が用意されていますが、導入も簡単に済ませたいという目標があったため今回は導入対象のOSに依存しないエージェントスクリプトを利用するインストール方法を採用しています。
エージェントスクリプトを利用するインストール方法の場合、Github上にスクリプトを置いておき、初期セットアップ時に実行するだけでいいので準備コスト等がほとんどかかりません。
https://cloudone.trendmicro.com/docs/workload-security/computers-add-deployment-scripts/
https://cloudone.trendmicro.com/docs/workload-security/agent-install/

また、侵入防御機能や変更監視機能では環境に適したポリシー設定を自動で作成、設定してくれる推奨スキャン設定などがあり管理コストを下げることが出来ます。
https://cloudone.trendmicro.com/docs/workload-security/recommendation-scans/

・設定後の構成

図７：開発環境のセキュリティ保護の実施での設定後の構成

最後に

これでCloud9を使用した開発環境のセットアップおよびそのセキュリティ対策が出来ました。
Cloud9を使用し開発を行うことで複数人での開発でも環境に差分がなく開発環境構築に時間を取られることがなくなりました。
また、C1WSを導入することでマルウェアなどホストベースの脅威から開発環境を保護することも可能となりより安全に開発を行うことができるようになりました！
次回はGithub Actionsを利用したCI/CD環境の構築とパイプラインでのソースコードのセキュリティチェックについて記載します！

【連載記事】