はじめに

いろいろあって、Zscalerから取得したproxyログをSIEMに転送することになったので、ログの転送を仲立ちしてくれるNSSサーバをAWS上に構築しました。

構成

　基本的には、VPC上にAMIからEC2を構築し、InternetおよびSIEMとのルーティングができればよいシンプルな構成です。

　NSSサーバは上記PrivateSubnet内で「web」という文字が見えるものです。NSSサーバ自身はInternet宛にはNAT-GW、SIEM宛にはVGW経由で通信します。
　管理の際にはにはRDPやSSHなどを用いた直接接続はせず、同Subnet内の「ope」と書いてあるEC2を踏み台としたSSH接続とします。踏み台サーバにはSSMにて接続することで、管理のための穴を最小限にしています。（後述）

目標

・所謂「Well Architected」な構成とすること
・可能な限りセキュリティに気を配ること

手順ざっくり

以下の順番でコンポーネントのパラメータを設定していきました。
1.AWS
2.閉域接続調整
3.Zscaler

AWS

　AWSでは、以下のコンポーネントを利用しました。色々考え方、都合があるかと思いますが、今回は以下の順序で手掛けました。(もちろん、設定ミス・不足があれば随時遡りました)
　どのコンポーネントも、デフォルトのインスタンスは用いず新規で作成しました。

VPC
subnet
SecurityGroup
ElasticIP
NAT-GW
InternetGW
(閉域接続先の受け入れ設定）
Virtual Private GW
RoutingTable
IAM
SessionManager
EC2
CloudWatch / CloudTrail

VPC

　一つ大きなセグメント(/24)を作成し、2つのsubnet(/25)に分割しました。
　ちなみに、VPC内のアドレスのいくつかはAWSにて予約されています。例えば10.0.0.0/24内だと、、

10.0.0.0　ネットワークアドレス
10.0.0.1　VPCルータ用のアドレス
10.0.0.2　DNSサーバのIPアドレス
10.0.0.3　将来利用のためAWSが予約
10.0.0.255　ブロードキャストアドレス

と、要はホストアドレスの冒頭3つが使えません。
　参考：サブネット CIDR ブロック

VPCに属するサービス一覧

　結構いろいろあります。

subnet

　private subnet とpublic subnet の2つ作成しました。
　構成図の通り、EC2はInternetに曝さないようprivate側に設置し、public側に置いたNAT-GW経由での通信をさせるようにしています。

SecurityGroup

　こちらにまとめられているZscalerの仕様に則り必要最小限の穴あけとしました。EC2にアタッチする用です。

　実際には同一のType、Protocol、Destination、宛先IPアドレスを指定しているルールは異なる備考をつけていても複数作成で来ませんでしたので、キャプチャの通りには行きませんでした。
また、以下注意点です。
・Remote Supportの宛先IPアドレスは例の通り
・SIEMのIPアドレスは環境ごとに決める
・NTPやDNSは利用したいものが決まっていれば宛先IPアドレスを絞ってもよい。

もっと知りたい

・SecurityGroupはEC2にアタッチする場合は、EC2の有する全NICに適用されます。ただし、それぞれのNICに異なるSecurityGroupを適用することも可能のようです。
・NAT-GWにはSecurityGroupを適用できないため、連携しているEC2に適用する形のようです。
・SecurityGroupを適用できるインスタンス/できないインスタンスがどこかに一覧化されていないものか。。（コメント求ム）

Access-listとの違い

　こちらに詳しい。

#	設定単位	ステート
Security Group	インスタンス	フル
Access-list	サブネット	レス

　今回は扱いませんでしたが、SecurityGroupはルールにIPセグメントとポート番号を用いながら（Access-listと同様）、それらの代わりにSecurityGroup IDを用いることも可能です。LBを用いてEC2をAZ間で冗長する場合など、送信元IPが固定されないリソースを用いる場合にきめ細やかな制御が可能になるらしいです。

　他、Access-listはステートレスのため戻りの通信用にエフェメラルポートを考慮したルール作りをする必要があるとのこと。AWS上の説明はこちら。
※参考：エフェメラルポートとは？対策などをわかりやすく解説

　ほか、参考資料
【AWS】ネットワークACLとセキュリティグループの違いについて
 【AWS】ネットワークACLとセキュリティグループの使い分け

ElasticIP

　たしか、先んじて作成してからNAT-GWに適用しました。VPCサービスにてちょろちょろっと作成します。

作成後、紐づけ先のリソースを選択可能です。

NAT-GW

　VPCのリソースとして作成されます。たったこれだけでぴょろっと作れるのが驚きでした。設置先のsubnetはNAT-GWの作成中に選定します。

InternetGW

　こちらも、VPCのリソースとしてさくっと作成されます。

　作成後、VPCへのアタッチが必要です。

(閉域接続先の受け入れ設定)

　VGWを作成する前に、接続先を整えます。ここでは割愛します。
依頼するだけのことを依頼したら、後述するVPGWの「仮想インターフェース（VIF）」にて承認し、相互接続されます。

Vitrual Private GW

　全体の進め方はこちら。
1.VGWの作成
 2.仮想IFの承認
※引用元3連作の第１段 DXGWの作成は、今回割愛しました。
　DXGWはVGWとプライベートVIF をグループ化する機能であり、１つのVIFに対して複数のVPCを利用することができる＝接続先VPCを増やしやすい、管理しやすいというメリットがあります。
　VIFとVGWは直接接続することも可能なので、今回は１つのリージョンの１つのVPCのみをオンプレ接続するのでDXGWは用いずVGWに直収することにします。
※参考：AWS Direct Connect のよくある質問

　1.のVGWは、VPCもしくはDirectConnectから作成します。

VIF

　作成に当たり検討するべきパラメータを並べます。

ゲートウェイタイプ

　今回は、先述の通り１つのリージョンの１つのVPCのみをオンプレ接続するので「仮想プライベートゲートウェイ」を選択します。VPGWは作成済みなので、ここでアタッチします。

仮想インターフェイスのタイプ

　基本はプライベートかトランジットのどちらかみたいです。で、VGWを使う時がプライベートで、トランジットGWを使う時がトランジット。

※トランジットGW：①サイト間VPNの集約②DXGWとの接続の集約③VPCピアリングなくVPC間の通信が可能

　
　参考：AWS Transit Gatewayとは？概要や利用するメリットについて説明します
　　　　TGWの導入が効果的なケースや使わない場合の差分などまとまっていて面白かったです。
　※DXGWだけだとVPC間通信にVPCピアングが必要なうえDXGWではなくオンプレルータ折り返しとなるものの、TGWがあるとVPCピアリングは不要かつTGW経由となります。

IPアドレス

対向機器のIPアドレスとAWS側のIPアドレスをサブネットマスク長とともに指定します。

※参考：Direct Connect Gateway (DXGW)とVGWとVIFのまとめ
　　　　占有型？共有型？AWS Direct Connect の接続（Connection）と仮想インターフェース（VIF）関連の用語を整理してみた

Routing Table

　作成画面では、Routing Tableを設置したいVPCを選択します。

　作成後、個別にルーティングエントリを追加するとともに、設置したいsubnetを選択します。

　今回は、private subnetとpublic subnetのそれぞれ用にRouting Tableを作成しました。VPC内での通信を可能にするためのルーティングエントリはデフォルトで存在したので、同一VPC内であれば異なるsubnet間でも追加設定なしでルーティング可能です。
　宛先にAWSリソースを指定可能でわかりやすかったです。ちなみに、👇のNAT-GWはリソースに設置subnet内のアドレスが降られていました。10.0.0.175という微妙なところだったので、自分で固定IPを振ったEC2とバッティングしたりしないか心配。

private subnet用

　デフォルトゲートウェイをNAT-GWに、SOCあての通信をVGWをネクストホップに指定しています。
　NAT-GWは厳密には別subnetなのでネクストホップ的に指定されるのはなんとなく違和感なのですが、さっき書いたVPCルータがデフォルトゲートウェイとして仲立ちしてくれる模様。このケースだと10.0.0.1です。

　参考：ネットワークエンジニアが教える！AWSのVPCルーターの全て

public subnet用

　デフォルトゲートウェイはIGWです。

IAM

　ユーザや各種リソースといったエンティティにはIAMロールを割り当てることで権限管理をします。ロールには、①ポリシーと②許可の境界を割り当てることで、ロールの割り当てられたエンティティの権限をコントロールします。こんな感じです。

　エンティティにはロールのみしか割り当てることができないため（しかも１つ）、必要なポリシーをロールに割り当てる必要があります。ある種、ロールという箱を通じて権限のパッケージを作るイメージですね。
　「ユーザー」だけではなく「リソース」にもロールを付与しないとリソース間の相互通信ができません。例えばこちらの例では、EC2からS3を操作するために「AmazonS3FullAccess」ポリシーを追加しています。

　本環境では、後ほど紹介するCloudwatchのエージェントをインストールするために「CloudWatchAgentAdminPolicy」を、SSMのエージェントをインストールするために「AmazonSSMManagedInstanceCore」を、EC2に付与しています。

許可の境界

　作成したロールが有することのできる許可の上限値を設定します。作成したロールが高度な権限を有するロールを勝手に作り出さないよう、組織のポリシーに準拠したロールしか作成させないように制約づけるものです。
　ロールを問わずさせたくない動作は同じなので、境界を作成して置いたら権限管理が楽になる、というものみたいです。

Session Manager

　EC2にリモートデスクトップ接続する際に、SSH接続ではなくHTTPSで接続できます。併せて、Security GroupにてInbound通信のSSHの穴あけが不要であり、Outbound通信にてHTTPSを穴あけすればOKです。というか大抵はもともと開けているものなので追加の穴が不要です。
　
　手法は完全にこちらに則りました。
　図解で、もう踏み台要らずAWS SSM経由Windowsサーバーにリモートデスクトップ接続
　「quick setup」実施前に適切なロール（再掲：AmazonSSMManagedInstanceCore）を作成しておくこと、同「quick setup」はSSMしたいEC2を作成する前に実施しておくことが肝です。

EC2

　NSSサーバはAMIから、踏み台サーバはゼロから作成しました。
　NSSサーバはおそらくLinux(ディストリビューションは後述の経緯により不明)、踏み台サーバはWindows10です。
　AMIはこの辺から検索できますが、NSSサーバは確かZscaler社にアカウントIDとか伝えないと検索結果に表れなかった記憶。

CloudWatch / CloudTrail

今回は、以下の３つの観点から情報を吸い上げ管理できるようにしました。
①EC2のマシンリソース利用状況を測るための情報(パフォーマンスログ)
②EC2の動きを追うための情報(イベントログ)
③AWSリソースへの設定変更状況をたどるための情報(監査ログ)

　CloudWatchとCloudTrailの違いは、一言で言うと着目するのがモノかヒトか、とのこと。（こちら）
　※参考CloudWatch(Logs)とCloudTrailについて。
　　　　AWS CloudTrailを活用したイベント管理

①EC2のマシンリソース利用状況を測るための情報(パフォーマンスログ)

　メトリクス > 所望のリソースおよびメトリクス

　このようなグラフが出てきます。１５か月分くらいは見られそうな感じ。

②EC2の動きを追うための情報(イベントログ)

　NSSサーバそのものではなく踏み台サーバにCloudWatchエージェントをインストールし、イベントログを収集しました。理由は後述。
　※参考：EC2 WindowsインスタンスにCloudWatchエージェントをインストールして稼働させる
　EC2がSSMで接続できること、適切なポリシーを付与したロールがついていることがミソですね。

１．EC2にCloudWatchAgentAdminPolicy のPolicyをアタッチする

EC2に以下のPolicyをアタッチします。
　※参考：CloudWatchAgentAdminPolicyとCloudWatchAgentServerPolicyの違いを調べた

２．SSM Run CommandでCloudwatch agentをインストールする

　EC2にリモアクせずともagentをインストールできるみたいです。
　※参考：[AWS]CloudwatchエージェントをRunCommandのみでインストールする

３．amazon-cloudwatch-agent-config-wizard.exe でAgentの設定ファイルを作成する

　収集するログなどを決めていきます。
　※参考：ウィザードを使用して CloudWatch エージェント設定ファイルを作成する

　まぁ結局踏み台サーバのログであってNSSサーバの情報ではないんですけれどね。お遊びです。
ただ、正直どんなログが取れてどのような情報を得られることになるのかが全く分からないので知見ある方は、コメントいただけると嬉しいです。。
※そもそも「イベントログ」ってなに？？「テキストログ」ってなに？？ほかにないの？？そのほかのCPU利用率とかパフォーマンスに関することはログに残らないの？？LinuxとWindowsは違う？？

４．agentを起動する

　agentを起動できればログ収集開始です。
　※参考：CloudWatchAgentをインストールしてサーバーの監視を行う④(Windows用CloudWatchAgentConfigファイルの生成、CloudWatchAgent起動）
　　　　サーバーで CloudWatch エージェントをインストールおよび実行する

こんなログが取れます

　CloudWatch > ロググループ > 作成したロググループを選択

　なんかいろいろ出てきます。正直わからん。

　こちらによると、一連のログイベントがログストリームとしてまとまっているようです。一連ってなんだ（ぜひコメントください。。）

　EC2だけではなく、VPCやRoute53からも同様のログを収集することができるみたいですね。

　例えばVPCのフローログだと、このようにVPC側での作業になる。適切なロールをVPCに付与することが必要みたいです。
参考：VPCフローログの取得方法（CloudWatch Logsに保存）

③AWSリソースへの設定変更状況をたどるための情報(監査ログ)

　いつ、誰が、何を、どのように触ったかのヒトに着目したログです。CloudTrailを使うことにしました。
　ただ、CloudTrailは通知機能がないようなので、特定の所作があったときに通知したいときはCloudWatch Logsとの連携が必要みたいです。
　また、デフォルトでは90日間しかログを保管できないようなので(ちなみに無償)、それ以上の期間での保管が必要な場合にはS3との連携が必要です。

こんなログが取れます

　CSVやJSONでダウンロードもできるみたいです。S3に保存することもできるらしい。

その他

命名規則

このブログを参考にしました。今回は、以下。
用途-リソース名-番号

見積

　ここから使えます。出来上がった版ごとにURLが発行されるので、なくさないようにしたいですね。

Zscaler

NSSサーバ

　言わずと知れたSASEソリューションですが、proxyログをSIEMに収集するためには「NSSサーバ」とやらを構築し、ログの伝搬を仲立ちさせてあげる必要があるみたいです。こんな感じ。

　NSSはNanolog Streming Serviceの意のようでして、名前の通りNSSサーバはログをSIEMにストリーミングするだけで自身は腹蔵しません。
　トラフィックフローとしては、（若干直観とは反しますが）SecurityGroupからもわかる通りNSSサーバがZscalerクラウドに対してログをGETしに行くoutbound通信が主です（Zscalerクラウドからログが流れてくるわけではない）。
　proxyログとFWログの両方が必要な場合、最低２台のNSSサーバが必要です。

AWSの他、AzureやvSphere上にも構築することができるみたいです。

作業手順

　全体的にはこちら（再掲）。EC2のマシンスペックを計算するためのツールが設けられていました。
　証明書を準備したりなど手数が意外と多いので、時間の制約がある場合は、事前にできることは可能な限り済ませておくとよいかもしれません。

注意点

Zscaler社がマシンイメージを作りこんだ、プロプライエタリな逸品です。おいそれと各種agentをインストールすることができませんでした。。（諦めました）
プロプライエタリシステム

経緯

agentのインストールに四苦八苦していたとき、利用するコマンドはどうもLinuxのディストリビューションごとに異なるようだぞとのことで、NSSサーバのディストリビューションを調べるためのコマンドを調べてみました。
すると/etc/配下に各ディストリビューション名を冠したファイルがあること、もしくは/etc/issue を確認すればディストリビューションやバージョンの情報が分かることがわかりましたが、どうもNSSサーバにはどのファイルもない。issueに似た名前のファイルがあったのでcatで読んでみたら「プライエタリだから注意！！」のようなwarningが。あー、これは触っちゃいけないやつなんだなぁと判断して諦めました。

まとめ

　以上、うまくいったりいかなかったりする部分を孕みながら総体としては出来上がりました。正直SSMやCloudWatchのエージェントのインストールはもう一回やれと言われてもできる気がしないしログは読めないし取りたいものが取れているのかわからないので見直さないとなのですが、まぁ成功ということにしましょう。

その他

SOC (Securit Operation Senter)

　企業のネットワークやデバイスを監視して、セキュリティ危機から守るための専門組織のこと。（SOCとは？必要性や他のセキュリティとの違い・構築方法を解説）

　こちらから

SIEM(Security Information and Event Management)

　ファイアウォールやIDS/IPS、各種サーバーやアプリケーションなど、ITシステムを構成する様々な機器やソフトウェアが生成するログデータを一箇所に集約するもので、SOCで用いられるツールのこと。
　ログデータの収集と保管を表すSIMと、リアルタイム分析とアラート生成を表すSEMの2つを力点とする。
　※参考：SIEMとは？意味や特徴・メリットをわかりやすく解説

参照

サブネット CIDR ブロック
 Amazon Web Services用NSS展開ガイド
 なぜネットワークACLでなくセキュリティグループで細かいトラフィック制御を行なうのか
 一時ポート
 エフェメラルポートとは？対策などをわかりやすく解説
 【AWS】ネットワークACLとセキュリティグループの違いについて
 【AWS】ネットワークACLとセキュリティグループの使い分け
［【AWS】IAMロールとIAMポリシーの違いとは？わかりやすく解説！］(https://programmingnote.jp/archives/1897)

図解で、もう踏み台要らずAWS SSM経由Windowsサーバーにリモートデスクトップ接続
 【Direct ConnectでオンプレとAWS環境を繋ぐ！第1弾】　Direct Connect Gateway (DXGW) の構築手順
 【Direct ConnectでオンプレとAWS環境を繋ぐ！第2弾】　仮想プライベートゲートウェイ(VGW)の構築手順
 【Direct ConnectでオンプレとAWS環境を繋ぐ！第3弾】　仮想インターフェイス（VIF）の承認作業手順
 AWS Direct Connect のよくある質問
 Direct Connect Gateway (DXGW)とVGWとVIFのまとめ
 占有型？共有型？AWS Direct Connect の接続（Connection）と仮想インターフェース（VIF）関連の用語を整理してみた
 AWS Transit Gatewayとは？概要や利用するメリットについて説明します
 ネットワークエンジニアが教える！AWSのVPCルーターの全て

EC2 WindowsインスタンスにCloudWatchエージェントをインストールして稼働させる
 AWS_CloudWatchとCloudTrailの違い　#401
CloudWatch(Logs)とCloudTrailについて
 CloudWatchAgentAdminPolicyとCloudWatchAgentServerPolicyの違いを調べた
 [AWS]CloudwatchエージェントをRunCommandのみでインストールする
 ウィザードを使用して CloudWatch エージェント設定ファイルを作成する
 サーバーで CloudWatch エージェントをインストールおよび実行する
 Amazon CloudWatch Logs でログを読むための手法メモ
 VPCフローログの取得方法（CloudWatch Logsに保存）

【保存版】AWSリソース名の決め方と命名規則
 プロプライエタリシステム
 【3分理解】Linuxディストリビューションの確認方法

SOCとは？必要性や他のセキュリティとの違い・構築方法を解説
 SOC（Security Operation Center）とは
 SIEMとは？意味や特徴・メリットをわかりやすく解説