【第二回】
SmartKobanzaki2のAWS移行プロジェクト
~AWS環境の整備~
公開日
2022年12月24日
皆さん、こんにちは!トレンドマイクロでテクニカルサポートをしている野木です。
今回はテクニカルサポート部門で開発、運用している自動化プログラムであるSmartKobanzaki2(以下Kobanzaki)のAWS移行および環境のセキュア化についてのご紹介をさせていただきます。
オンプレ環境で動作しているブログラムをどのようにAWS上へ移行したかや、どのようなセキュリティ対策を行っているのかを掲載できればと考えています。
なお、本ブログは第二回となります。過去は以下となりますためぜひご覧ください。
以前のブログのおさらい
第一回ではKobanzakiの概要やAWS移行の構想、そしてAWS環境に適したセキュリティ設定を行うために利用する弊社製品のTrend Micro Cloud Oneについて記載しました。
本ブログ(第二回)での目標と設定実施について
・本ブログ(第二回)での設定項目
第二回の本ブログは以下を設定し、AWS上に移行するためのベースとなるAmazon VPCの作成やオンプレ環境との接続といったネットワークレイヤの設定、およびネットワークレイヤでのセキュリティ対策を行っていきます。
・AWS 上でのベース環境の作成
・オンプレミス環境との接続
・AWS Secrets Manager の設定およびアクセス設定
・ネットワーク環境のセキュリティ保護の実施
・目標構成
図1:本ブログでの目標構成図
・設定の実施
< 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で2つのCIDRがある状態となっています。
※Instanceサブネット、Transit GW サブネットのみ社内IP CIDR
https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/working-with-vpcs.html#add-ipv4-cidr
・設定後の構成
図2: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/
・設定後の構成
図3:オンプレミス環境との接続での設定後の構成
< AWS Secrets Manager の設定およびアクセス設定 >
Kobanzakiで使用している各クレデンシャルを保存する用の Secrets Manager の設定を行います。
この際、Secrets Managerのリソースベースポリシーを使用し、特定のVPCかつCIDRまたは特定ロールからのみのアクセス許可という設定を行います。
上記設定を行うため、作成したVPC内にVPC Endpointを作成しVPC や IP アドレスでの判断を可能にし、Secrets Managerのリソースベースポリシーに以下のような設定を行います。
図4:Secrets Managerに設定するリソースベースポリシー例
また、アクセスするリソースにもSecrets Managerリソースへのアクセス許可ポリシーが含まれた以下のようなIAMロールを付与していきます。
図5:Secrets Managerにアクセスするリソースに付与するアクセス許可ポリシー例
・設定後の構成
図6: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 環境を操作するのに必要な権限を取得します。
図7:C1NSコンソールHome画面
手順としては、Launch Stack をクリックすることで AWS CloudFormation(以下CloudFormation) が起動し、IAMロールを作成することが出来ます。
図8:C1NSとAWSアカウント連携を行う画面
図9:IAMを作成するCloudFormationスタック作成画面
CloudFormationで作成されたIAMロールを C1NS に登録します。これを行うことにより、NSHIの展開やAssets機能を利用したAWS上でのVPC環境保護チェックを行うことができます。
図10:C1NSとAWSアカウント連携成功画面
2. エンドポイントの作成
C1NSにAWSアカウント連携が行われると、Hosted Infrastructureの画面で連携したAWSアカウントのVPC一覧が表示されるため導入予定のVPCを探しDeploy Protectionをクリックします。
図11:Hosted Infrastructure の画面(導入前)
Deploy Protection をクリックすると Hosted Infrastructure を導入するために必要なエンドポイントを作成する画面になります。
※この際サブネットは新規作成または既存のものの指定が選択可能となります。
図12:NSHI用エンドポイントの作成画面(作成前)
図13:NSHI用エンドポイントの作成画面(作成後)
エンドポイントの作成画面でステータスがCreation StartedになるとAWSコンソール上ではCloudFormationが自動でスタックの展開が開始しエンドポイントが作成されます。
図14:エンドポイントを作成するCloudFormationの画面
図15:Hosted Infrastructure の画面(導入後)
3. ルーティングの変更
エンドポイントの作成が完了すればすでにNSHI側での準備は完了となるため、ルートテーブルを編集しすべての通信がこの エンドポイントを通過するように編集します。
今回の環境では以下のような通信経路となるようルートテーブルを変更します。
インバウンド検査
TGW -> Endpoints -> Instances
アウトバウンド検査
Instances -> Endpoints -> NAT Gateway -> Internet
Instances -> Endpoints -> TGW
図16:ルートテーブル変更後の通信経路図
NSHIで正常に検査が行われているかを確認するために、インスタンスからアウトバウンド検査テストを行います。
検出テスト方法の参考:
https://cloudone.trendmicro.com/docs/network-security/NS_Action/#attack-simulation
検出ログはAmazon CloudWatchへ出力されます。
図17:NSHIの検査テストログ
またC1NSコンソール上ではNSHIで検査したトラフィック量が確認可能です。
図18:NSHIでの検査したトラフィック量の確認画面
・設定後の構成
図19:ネットワーク環境のセキュリティ保護の実施での設定後の構成
最後に
これで開発環境、本番環境を移行するVPCの展開やオンプレミス環境との接続、そのセキュリティ対策が出来ました。
NSHIはCloudFormationで展開されるため、とても簡単にネットワークの保護が可能になっていますね。
また、セキュリティアプライアンスがトレンドマイクロの管理となるためVPCにセキュリティアプライアンス関連のリソースを展開して管理しなければならないリソースが増えることやAmazon EC2インスタンスとしての管理が不要というのは余計な管理コストが発生せずに便利でいいですね!
次回はAWS上での開発環境の構築とホスト端末でのセキュリティ対策について記載します!
執筆
野木 健
トレンドマイクロ株式会社 エンタープライズSE本部
エンタープライズテクニカルサポート部 ネットワークサポート課
2022 APN ALL AWS Certifications Engineers
2022 APN AWS Top Engineers (Software)
監修
根本 恵理子
トレンドマイクロ株式会社 セキュリティエキスパート本部
セールスエンジニアリング部 サーバセキュリティチーム
ソリューションアーキテクト
CDN業界にて大規模なWebサービスの負荷分散やパフォーマンス改善、セキュリティ対策等の提案・導入を経験した後にセキュリティ業界へ転身し7年業務に従事。Trend Cloud Oneシリーズのソリューションアーキテクトとして、クラウド全体のセキュリティ対策の検討やストレージ環境に対するセキュリティ対策の普及に注力。またトレンドマイクロとAWSのアライアンスにてTech担当をしており、共催イベント、エンジニア連携企画等のリードに従事。
電子公告 | ご利用条件 | 個人情報保護方針 | Privacy and Legal |利用者情報の外部送信について | 製品使用許諾契約 |プレスリリース | サポート | サイトマップ | RSS
Copyright ©2024 Trend Micro Incorporated. All rights reserved