【第二回】
SmartKobanzaki2のAWS移行プロジェクト
～AWS環境の整備～

以前のブログのおさらい

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

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

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

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

・AWS 上でのベース環境の作成
・オンプレミス環境との接続
・AWS Secrets Manager の設定およびアクセス設定
・ネットワーク環境のセキュリティ保護の実施

・目標構成

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

・設定の実施

< AWS 上でのベース環境の作成 >

Amazon VPC(以下VPC)および各サブネットを作成し、以降の手順で必要になる下準備をします。
※Kobanzakiはインターネットからのインバウンド通信を必要としないため、パブリックサブネットに展開するのは NAT Gatewayのみとなります。
また、NAT Gatewayがあるのにもかかわらず、VPC Endpoint用のサブネットを準備するのはAWS Secrets Manager(以下Secrets Manager)へのアクセス制限をする関係です ※後述
なお、AWS Transit Gateway(以下TGW)用のサブネットを作成するのはインスタンスを同居させるとTGWの経路の影響を受けるためとなります。
参考：
https://docs.aws.amazon.com/ja_jp/vpc/latest/tgw/tgw-best-design-practices.html
https://d1.awsstatic.com/webinars/jp/pdf/services/20191113_AWS-BlackBelt_Transit_Gateway.pdf

また、社内で使用しているIPアドレスの余剰が少ないため本VPCでは社内アクセス用のCIDRとその他リソース用のCIDRで２つのCIDRがある状態となっています。
※Instanceサブネット、Transit GW サブネットのみ社内IP CIDR
https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/working-with-vpcs.html#add-ipv4-cidr

・設定後の構成

図２：AWS 上でのベース環境の作成での設定後の構成

< オンプレミス環境との接続 >

※会社で使用している既存の TGW に接続を行います。
上記作成したTGW用のサブネットに新たにアタッチメントを作成し、オンプレミス環境向けのルートをInstanceサブネットに設定することでオンプレミス向けの通信を可能にします。

また、社内リソースへのアクセスには社内DNSサーバを使用し名前解決を行う必要があるため、VPCで新たにDNS の設定を行う必要があります。
この時、VPC からの通信は VPC の DNS サーバ、社内リソースの名前解決のみ社内 DNS サーバを使用したいため、Route53 Resolverアウトバウンドエンドポイントを使用します。
※エンドポイントを作成し、社内ドメインへの名前解決ルールを作成します。
https://aws.amazon.com/jp/premiumsupport/knowledge-center/route53-resolve-with-outbound-endpoint/

・設定後の構成

図３：オンプレミス環境との接続での設定後の構成

< AWS Secrets Manager の設定およびアクセス設定 >

Kobanzakiで使用している各クレデンシャルを保存する用の Secrets Manager の設定を行います。
この際、Secrets Managerのリソースベースポリシーを使用し、特定のVPCかつCIDRまたは特定ロールからのみのアクセス許可という設定を行います。

上記設定を行うため、作成したVPC内にVPC Endpointを作成しVPC や IP アドレスでの判断を可能にし、Secrets Managerのリソースベースポリシーに以下のような設定を行います。

図４：Secrets Managerに設定するリソースベースポリシー例

また、アクセスするリソースにもSecrets Managerリソースへのアクセス許可ポリシーが含まれた以下のようなIAMロールを付与していきます。

図５：Secrets Managerにアクセスするリソースに付与するアクセス許可ポリシー例

・設定後の構成

図６：AWS Secrets Manager の設定およびアクセス設定での設定後の構成

ネットワーク環境のセキュリティ保護の実施

AWS環境に構築したインスタンスが不正な宛先へのインターネット通信や、社内へ不正なパラメータを持った通信を通さないためにインターネットへのアウトバウンド通信およびTGWを介したオンプレミス環境との通信を検査するCloud One – Network Security(以下C1NS)を導入します。

C1NS とは既存のアーキテクチャにシームレスに導入することが可能なクラウドIPS製品となります。インバウンドおよびアウトバウンド両方の通信を検査し仮想パッチによる複数の脅威ベクトルに対する高度な脅威防御をクラウドインフラストラクチャに対して提供します。
https://cloudone.trendmicro.com/docs/network-security/Getting_started/

また、ここではなるべくプログラムの開発に集中したいため、セキュリティアプライアンスの管理が不要なCloud One – Network Security Hosted Infrastructure(以下NSHI)を採用しました。
NSHIはセキュリティアプライアンスのバージョンアップやAWS上でのインスタンスとしての管理などをトレンドマイクロ側で行うモデルとなります。
https://cloudone.trendmicro.com/docs/network-security/NSMS_intro/

・導入方法

以下の手順でNSHIを導入することが出来ます。
1. アカウント連携
2. エンドポイントの作成
3. ルーティングの変更

1. アカウント連携

C1NSコンソールのHomeからAdd cloud accountをクリックし、AWS 環境を操作するのに必要な権限を取得します。

図７：C1NSコンソールHome画面

手順としては、Launch Stack をクリックすることで AWS CloudFormation(以下CloudFormation) が起動し、IAMロールを作成することが出来ます。

図８：C1NSとAWSアカウント連携を行う画面

図９：IAMを作成するCloudFormationスタック作成画面

CloudFormationで作成されたIAMロールを C1NS に登録します。これを行うことにより、NSHIの展開やAssets機能を利用したAWS上でのVPC環境保護チェックを行うことができます。

図１０：C1NSとAWSアカウント連携成功画面

2. エンドポイントの作成

C1NSにAWSアカウント連携が行われると、Hosted Infrastructureの画面で連携したAWSアカウントのVPC一覧が表示されるため導入予定のVPCを探しDeploy Protectionをクリックします。

図１１：Hosted Infrastructure の画面（導入前）

Deploy Protection をクリックすると Hosted Infrastructure を導入するために必要なエンドポイントを作成する画面になります。
※この際サブネットは新規作成または既存のものの指定が選択可能となります。

図１２：NSHI用エンドポイントの作成画面（作成前）

図１3：NSHI用エンドポイントの作成画面（作成後）

エンドポイントの作成画面でステータスがCreation StartedになるとAWSコンソール上ではCloudFormationが自動でスタックの展開が開始しエンドポイントが作成されます。

図１4：エンドポイントを作成するCloudFormationの画面

図１5：Hosted Infrastructure の画面（導入後）

3. ルーティングの変更

エンドポイントの作成が完了すればすでにNSHI側での準備は完了となるため、ルートテーブルを編集しすべての通信がこの エンドポイントを通過するように編集します。
今回の環境では以下のような通信経路となるようルートテーブルを変更します。
インバウンド検査
TGW -> Endpoints -> Instances
アウトバウンド検査
Instances -> Endpoints -> NAT Gateway -> Internet
Instances -> Endpoints -> TGW

図１6：ルートテーブル変更後の通信経路図

NSHIで正常に検査が行われているかを確認するために、インスタンスからアウトバウンド検査テストを行います。
検出テスト方法の参考：
https://cloudone.trendmicro.com/docs/network-security/NS_Action/#attack-simulation

検出ログはAmazon CloudWatchへ出力されます。

図１7：NSHIの検査テストログ

またC1NSコンソール上ではNSHIで検査したトラフィック量が確認可能です。

図１8：NSHIでの検査したトラフィック量の確認画面

・設定後の構成

図１9：ネットワーク環境のセキュリティ保護の実施での設定後の構成

最後に

これで開発環境、本番環境を移行するVPCの展開やオンプレミス環境との接続、そのセキュリティ対策が出来ました。
NSHIはCloudFormationで展開されるため、とても簡単にネットワークの保護が可能になっていますね。
また、セキュリティアプライアンスがトレンドマイクロの管理となるためVPCにセキュリティアプライアンス関連のリソースを展開して管理しなければならないリソースが増えることやAmazon EC2インスタンスとしての管理が不要というのは余計な管理コストが発生せずに便利でいいですね！
次回はAWS上での開発環境の構築とホスト端末でのセキュリティ対策について記載します！

【連載記事】