AWSで「Well Architected」な構成を作ってみた

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

1. VPC
2. subnet
3. SecurityGroup
4. ElasticIP
5. NAT-GW
6. InternetGW
7. (閉域接続先の受け入れ設定）
8. Virtual Private GW
9. RoutingTable
10. IAM
11. SessionManager
12. EC2
13. 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 ブロック](https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/subnet-sizing.html)

### VPCに属するサービス一覧
　結構いろいろあります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/469705/db3bbb48-6764-f835-173f-796eee248ae2.png)

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

## SecurityGroup
　[こちら](https://help.zscaler.com/ja/zia/nss-deployment-guide-amazon-web-services)にまとめられているZscalerの仕様に則り必要最小限の穴あけとしました。EC2にアタッチする用です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/469705/d701561f-4d2e-ebf8-e53c-7a0d19529f0c.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/469705/5c214b62-6b3b-647a-3763-744ab91bf7bc.png)
　実際には同一の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との違い
　[こちら](https://dev.classmethod.jp/articles/why-i-prefer-sg-to-nacl/)に詳しい。
|# |設定単位 |ステート |
|:-: | :-: | :-: |
|Security Group |インスタンス |フル |
|Access-list |サブネット |レス |

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

　他、Access-listはステートレスのため戻りの通信用にエフェメラルポートを考慮したルール作りをする必要があるとのこと。AWS上の説明は[こちら](https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/nacl-ephemeral-ports.html)。
※参考：[エフェメラルポートとは？対策などをわかりやすく解説](https://it.webcli.jp/topics/ephemeralport/#:~:text=%E3%82%A8%E3%83%95%E3%82%A7%E3%83%A1%E3%83%A9%E3%83%AB%E3%83%9D%E3%83%BC%E3%83%88%E3%81%A8%E3%81%AF%E3%80%81%E3%82%AF%E3%83%A9%E3%82%A4%E3%82%A2%E3%83%B3%E3%83%88%E3%81%8C%E3%82%B5%E3%83%BC%E3%83%90%E3%83%BC%E3%81%A8%E3%81%AE%E9%80%9A%E4%BF%A1%E3%82%92%E8%A1%8C%E3%81%86%E9%9A%9B%E3%81%AB%E3%80%81%E4%B8%80%E6%99%82%E7%9A%84%E3%81%AB%E5%88%A9%E7%94%A8%E3%81%99%E3%82%8B%E3%83%9D%E3%83%BC%E3%83%88%E7%95%AA%E5%8F%B7%E3%81%AE%E3%81%93%E3%81%A8%E3%81%A7%E3%81%82%E3%82%8B%E3%80%82,%E3%82%AF%E3%83%A9%E3%82%A4%E3%82%A2%E3%83%B3%E3%83%88%E3%81%AF%E3%80%81%E3%82%B5%E3%83%BC%E3%83%90%E3%83%BC%E3%81%A8%E3%81%AE%E9%80%9A%E4%BF%A1%E3%82%92%E9%96%8B%E5%A7%8B%E3%81%99%E3%82%8B%E9%9A%9B%E3%81%AB%E3%80%81OS%E3%81%AB%E3%82%88%E3%81%A3%E3%81%A6%E5%8B%95%E7%9A%84%E3%81%AB%E3%82%A8%E3%83%95%E3%82%A7%E3%83%A1%E3%83%A9%E3%83%AB%E3%83%9D%E3%83%BC%E3%83%88%E3%81%8C%E5%89%B2%E3%82%8A%E5%BD%93%E3%81%A6%E3%82%89%E3%82%8C%E3%82%8B%E3%80%82)

　ほか、参考資料
[【AWS】ネットワークACLとセキュリティグループの違いについて](https://qiita.com/tireidev/items/aa67e2829ff64d6aeb74)
[【AWS】ネットワークACLとセキュリティグループの使い分け](https://note.com/takashi_sakurada/n/n86eba45cba5f)

## ElasticIP
　たしか、先んじて作成してからNAT-GWに適用しました。VPCサービスにてちょろちょろっと作成します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/469705/bcb75827-7dd1-8df6-7d69-f9d22d67074a.png)

作成後、紐づけ先のリソースを選択可能です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/469705/83f46baf-a1cd-c5d8-3d8f-d70f426e3e16.png)

## NAT-GW
　VPCのリソースとして作成されます。たったこれだけでぴょろっと作れるのが驚きでした。設置先のsubnetはNAT-GWの作成中に選定します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/469705/39e02642-9562-abb3-0d0c-6b95d15c58a2.png)

## InternetGW
　こちらも、VPCのリソースとしてさくっと作成されます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/469705/f665aca2-4d6b-bd7c-047c-f13d41f8b96e.png)

　作成後、VPCへのアタッチが必要です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/469705/515b33d0-b7ef-e7da-65ac-6a459ae98f37.png)

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

## Vitrual Private GW
　全体の進め方はこちら。
[1.VGWの作成](https://blog.serverworks.co.jp/2021/12/21/090000)
[2.仮想IFの承認](https://blog.serverworks.co.jp/2022/02/14/180000)
※引用元3連作の[第１段 DXGWの作成](https://blog.serverworks.co.jp/2021/12/20/180000)は、今回割愛しました。
 　DXGWはVGWとプライベートVIF をグループ化する機能であり、１つのVIFに対して複数のVPCを利用することができる＝接続先VPCを増やしやすい、管理しやすいというメリットがあります。
　VIFとVGWは直接接続することも可能なので、今回は１つのリージョンの１つのVPCのみをオンプレ接続するのでDXGWは用いずVGWに直収することにします。
※参考：[AWS Direct Connect のよくある質問](https://aws.amazon.com/jp/directconnect/faqs/)

　1.のVGWは、VPCもしくはDirectConnectから作成します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/469705/553904db-f56c-f5f2-0989-f4674d69133d.png)

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

### ゲートウェイタイプ
　今回は、先述の通り１つのリージョンの１つのVPCのみをオンプレ接続するので「仮想プライベートゲートウェイ」を選択します。VPGWは作成済みなので、ここでアタッチします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/469705/6a020c7f-9e9f-7b3c-bafb-78fe7f4db1a5.png)

### 仮想インターフェイスのタイプ
　基本はプライベートかトランジットのどちらかみたいです。で、VGWを使う時がプライベートで、トランジットGWを使う時がトランジット。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/469705/5238f718-7276-8ed6-ed42-a4750b493794.png)

※**トランジットGW**：①サイト間VPNの集約②DXGWとの接続の集約③VPCピアリングなくVPC間の通信が可能
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/469705/deaf406c-31c0-e7b7-8fb7-11bcaf5c00d0.png)
　![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/469705/a52bee52-4e7f-8e68-fd28-ec588856c742.png)
　参考：[AWS Transit Gatewayとは？概要や利用するメリットについて説明します](https://atbex.attokyo.co.jp/blog/detail/96/)
 　　　　TGWの導入が効果的なケースや使わない場合の差分などまとまっていて面白かったです。
 　※DXGWだけだとVPC間通信にVPCピアングが必要なうえDXGWではなくオンプレルータ折り返しとなるものの、TGWがあるとVPCピアリングは不要かつTGW経由となります。

### IPアドレス
対向機器のIPアドレスとAWS側のIPアドレスをサブネットマスク長とともに指定します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/469705/2a2d27e3-e1ed-675b-9225-4910bf520ada.png)

※参考：[Direct Connect Gateway (DXGW)とVGWとVIFのまとめ](https://qiita.com/mmurm/items/abf390def0ae6dbd1950)
　　　　[占有型？共有型？AWS Direct Connect の接続（Connection）と仮想インターフェース（VIF）関連の用語を整理してみた](https://dev.classmethod.jp/articles/aws-direct-connect-connection-vif-organize-terms/)

## Routing Table
　作成画面では、Routing Tableを設置したいVPCを選択します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/469705/7cb06693-a4f9-0bf8-2977-6703dcd6851d.png)
　作成後、個別にルーティングエントリを追加するとともに、設置したい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です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/469705/4b2de9dc-3561-271b-e3f7-44dbaa46dfb4.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/469705/92e47430-c0a9-4f10-d08c-1dd831201793.png)
 　参考：[ネットワークエンジニアが教える！AWSのVPCルーターの全て](https://koejima.com/archives/1950/)

### public subnet用
　デフォルトゲートウェイはIGWです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/469705/508198a8-384b-b563-594d-9032937a01c7.png)


## IAM
　ユーザや各種リソースといったエンティティにはIAMロールを割り当てることで権限管理をします。ロールには、①ポリシーと②許可の境界を割り当てることで、ロールの割り当てられたエンティティの権限をコントロールします。こんな感じです。
 ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/469705/98bba4bd-d431-8b88-dfd3-31fa1f33e785.png)

　エンティティにはロールのみしか割り当てることができないため（しかも１つ）、必要なポリシーをロールに割り当てる必要があります。ある種、ロールという箱を通じて権限のパッケージを作るイメージですね。
 　「ユーザー」だけではなく「リソース」にもロールを付与しないとリソース間の相互通信ができません。例えば[こちら](https://programmingnote.jp/archives/1897)の例では、EC2からS3を操作するために「AmazonS3FullAccess」ポリシーを追加しています。
  
  　本環境では、後ほど紹介するCloudwatchのエージェントをインストールするために「CloudWatchAgentAdminPolicy」を、SSMのエージェントをインストールするために「AmazonSSMManagedInstanceCore」を、EC2に付与しています。

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

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

## EC2
　NSSサーバはAMIから、踏み台サーバはゼロから作成しました。
　NSSサーバはおそらくLinux(ディストリビューションは後述の経緯により不明)、踏み台サーバはWindows10です。
　AMIはこの辺から検索できますが、NSSサーバは確かZscaler社にアカウントIDとか伝えないと検索結果に表れなかった記憶。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/469705/bdf04377-abe3-ada5-5366-9fb9ca6e7ac1.png)

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

　CloudWatchとCloudTrailの違いは、一言で言うと着目するのがモノかヒトか、とのこと。（[こちら](https://note.com/ym202110/n/nc22c5d68c924)）
　※参考[CloudWatch(Logs)とCloudTrailについて](https://www.acrovision.jp/service/aws/?p=2222)。
　　　　[AWS CloudTrailを活用したイベント管理](https://business.ntt-east.co.jp/content/cloudsolution/column-28.html)

### ①EC2のマシンリソース利用状況を測るための情報(パフォーマンスログ)
　メトリクス > 所望のリソースおよびメトリクス
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/469705/2963b7cd-9b7e-6e45-eeb2-75610754acc6.png)
　このようなグラフが出てきます。１５か月分くらいは見られそうな感じ。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/469705/3a812360-b9bd-7add-8d09-33f5f2b25160.png)

### ②EC2の動きを追うための情報(イベントログ)
　NSSサーバそのものではなく踏み台サーバにCloudWatchエージェントをインストールし、イベントログを収集しました。理由は後述。
 　※参考：[EC2 WindowsインスタンスにCloudWatchエージェントをインストールして稼働させる](https://dev.classmethod.jp/articles/launch-cwagent-on-ec2-windows-instances/)
  　EC2がSSMで接続できること、適切なポリシーを付与したロールがついていることがミソですね。

### １．EC2にCloudWatchAgentAdminPolicy のPolicyをアタッチする
 EC2に以下のPolicyをアタッチします。
　※参考：[CloudWatchAgentAdminPolicyとCloudWatchAgentServerPolicyの違いを調べた](https://qiita.com/curlneko/items/f38533e7f949e7f6456b)

### ２．SSM Run CommandでCloudwatch agentをインストールする
　EC2にリモアクせずともagentをインストールできるみたいです。
 　※参考：[[AWS]CloudwatchエージェントをRunCommandのみでインストールする](https://qiita.com/Nacht/items/82145082cb96c6abeeff)

### ３．amazon-cloudwatch-agent-config-wizard.exe でAgentの設定ファイルを作成する
　収集するログなどを決めていきます。
 　※参考：[ウィザードを使用して CloudWatch エージェント設定ファイルを作成する](https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/create-cloudwatch-agent-configuration-file-wizard.html)

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

### ４．agentを起動する
　agentを起動できればログ収集開始です。
　※参考：[CloudWatchAgentをインストールしてサーバーの監視を行う④(Windows用CloudWatchAgentConfigファイルの生成、CloudWatchAgent起動）](https://qiita.com/tonkatsu_oishi/items/7abed083f1d5f1b45a7f)
 　　　　 [サーバーで CloudWatch エージェントをインストールおよび実行する](https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/install-CloudWatch-Agent-commandline-fleet.html)

### こんなログが取れます
　CloudWatch > ロググループ > 作成したロググループを選択
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/469705/27f02b2a-73b6-478e-51d4-2057491f734d.png)
　なんかいろいろ出てきます。正直わからん。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/469705/4bd6c72b-e65d-b46a-8e91-e74cc1b84ece.png)

　[こちら](https://qiita.com/Shigai/items/8739f5f0fa524433aabe)によると、一連のログイベントがログストリームとしてまとまっているようです。一連ってなんだ（ぜひコメントください。。）

　EC2だけではなく、VPCやRoute53からも同様のログを収集することができるみたいですね。
 ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/469705/ac538efc-2b48-dee6-a6b7-149423b48f72.png)
 　例えばVPCのフローログだと、このようにVPC側での作業になる。適切なロールをVPCに付与することが必要みたいです。
  参考：[VPCフローログの取得方法（CloudWatch Logsに保存）](https://qiita.com/kerorinfather/items/64c3ca83017e521d9917)

### ③AWSリソースへの設定変更状況をたどるための情報(監査ログ)
　いつ、誰が、何を、どのように触ったかのヒトに着目したログです。CloudTrailを使うことにしました。
 　ただ、CloudTrailは通知機能がないようなので、特定の所作があったときに通知したいときはCloudWatch Logsとの連携が必要みたいです。
　また、デフォルトでは90日間しかログを保管できないようなので(ちなみに無償)、それ以上の期間での保管が必要な場合にはS3との連携が必要です。

### こんなログが取れます
　CSVやJSONでダウンロードもできるみたいです。S3に保存することもできるらしい。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/469705/ef46a634-ee72-b552-9d9d-18f05c068555.png)

## その他
### 命名規則
[このブログ](https://zenn.dev/kaoru_dev/articles/df589681a31320)を参考にしました。今回は、以下。
**用途-リソース名-番号**

### 見積
　[ここ](https://calculator.aws/#/)から使えます。出来上がった版ごとにURLが発行されるので、なくさないようにしたいですね。

# Zscaler
## NSSサーバ
　言わずと知れたSASEソリューションですが、proxyログをSIEMに収集するためには「NSSサーバ」とやらを構築し、ログの伝搬を仲立ちさせてあげる必要があるみたいです。こんな感じ。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/469705/2826faec-6b34-7f56-b5b9-f4eae037fb24.png)
　NSSはNanolog Streming Serviceの意のようでして、名前の通りNSSサーバはログをSIEMにストリーミングするだけで自身は腹蔵しません。
　トラフィックフローとしては、（若干直観とは反しますが）SecurityGroupからもわかる通りNSSサーバがZscalerクラウドに対してログをGETしに行くoutbound通信が主です（Zscalerクラウドからログが流れてくるわけではない）。
　proxyログとFWログの両方が必要な場合、最低２台のNSSサーバが必要です。

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

### 作業手順
　全体的には[こちら](https://help.zscaler.com/ja/zia/nss-deployment-guide-amazon-web-services)（再掲）。EC2のマシンスペックを計算するためのツールが設けられていました。
　証明書を準備したりなど手数が意外と多いので、時間の制約がある場合は、事前にできることは可能な限り済ませておくとよいかもしれません。

### 注意点
 Zscaler社がマシンイメージを作りこんだ、プロプライエタリな逸品です。おいそれと各種agentをインストールすることができませんでした。。（諦めました）
[プロプライエタリシステム](https://e-words.jp/w/%E3%83%97%E3%83%AD%E3%83%97%E3%83%A9%E3%82%A4%E3%82%A8%E3%82%BF%E3%83%AA%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0.html)

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

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

# その他
## SOC (Securit Operation Senter)
　企業のネットワークやデバイスを監視して、セキュリティ危機から守るための専門組織のこと。（[SOCとは？必要性や他のセキュリティとの違い・構築方法を解説](https://www.menlosecurity.com/ja-jp/blog/soc)）
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/469705/150b0e11-afdc-23ad-ea18-a32f69b5cd8e.png)
　[こちら](https://www.ntt.com/bizon/glossary/e-s/soc.html?msockid=36dd928986126d7e3042815087686cc0)から

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

# 参照
[サブネット CIDR ブロック](https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/subnet-sizing.html)
[Amazon Web Services用NSS展開ガイド](https://help.zscaler.com/ja/zia/nss-deployment-guide-amazon-web-services)
[なぜネットワークACLでなくセキュリティグループで細かいトラフィック制御を行なうのか](https://dev.classmethod.jp/articles/why-i-prefer-sg-to-nacl/)
[一時ポート](https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/nacl-ephemeral-ports.html)
[エフェメラルポートとは？対策などをわかりやすく解説](https://it.webcli.jp/topics/ephemeralport/#:~:text=%E3%82%A8%E3%83%95%E3%82%A7%E3%83%A1%E3%83%A9%E3%83%AB%E3%83%9D%E3%83%BC%E3%83%88%E3%81%A8%E3%81%AF%E3%80%81%E3%82%AF%E3%83%A9%E3%82%A4%E3%82%A2%E3%83%B3%E3%83%88%E3%81%8C%E3%82%B5%E3%83%BC%E3%83%90%E3%83%BC%E3%81%A8%E3%81%AE%E9%80%9A%E4%BF%A1%E3%82%92%E8%A1%8C%E3%81%86%E9%9A%9B%E3%81%AB%E3%80%81%E4%B8%80%E6%99%82%E7%9A%84%E3%81%AB%E5%88%A9%E7%94%A8%E3%81%99%E3%82%8B%E3%83%9D%E3%83%BC%E3%83%88%E7%95%AA%E5%8F%B7%E3%81%AE%E3%81%93%E3%81%A8%E3%81%A7%E3%81%82%E3%82%8B%E3%80%82,%E3%82%AF%E3%83%A9%E3%82%A4%E3%82%A2%E3%83%B3%E3%83%88%E3%81%AF%E3%80%81%E3%82%B5%E3%83%BC%E3%83%90%E3%83%BC%E3%81%A8%E3%81%AE%E9%80%9A%E4%BF%A1%E3%82%92%E9%96%8B%E5%A7%8B%E3%81%99%E3%82%8B%E9%9A%9B%E3%81%AB%E3%80%81OS%E3%81%AB%E3%82%88%E3%81%A3%E3%81%A6%E5%8B%95%E7%9A%84%E3%81%AB%E3%82%A8%E3%83%95%E3%82%A7%E3%83%A1%E3%83%A9%E3%83%AB%E3%83%9D%E3%83%BC%E3%83%88%E3%81%8C%E5%89%B2%E3%82%8A%E5%BD%93%E3%81%A6%E3%82%89%E3%82%8C%E3%82%8B%E3%80%82)
[【AWS】ネットワークACLとセキュリティグループの違いについて](https://qiita.com/tireidev/items/aa67e2829ff64d6aeb74)
[【AWS】ネットワークACLとセキュリティグループの使い分け](https://note.com/takashi_sakurada/n/n86eba45cba5f)
［【AWS】IAMロールとIAMポリシーの違いとは？わかりやすく解説！］(https://programmingnote.jp/archives/1897)

[図解で、もう踏み台要らずAWS SSM経由Windowsサーバーにリモートデスクトップ接続](https://qiita.com/1Kano/items/1496d58b1293ff70c5ec)
[【Direct ConnectでオンプレとAWS環境を繋ぐ！第1弾】　Direct Connect Gateway (DXGW) の構築手順](https://blog.serverworks.co.jp/2021/12/20/180000)
[【Direct ConnectでオンプレとAWS環境を繋ぐ！第2弾】　仮想プライベートゲートウェイ(VGW)の構築手順](https://blog.serverworks.co.jp/2021/12/21/090000)
[【Direct ConnectでオンプレとAWS環境を繋ぐ！第3弾】　仮想インターフェイス（VIF）の承認作業手順](https://blog.serverworks.co.jp/2022/02/14/180000)
[AWS Direct Connect のよくある質問](https://aws.amazon.com/jp/directconnect/faqs/)
[Direct Connect Gateway (DXGW)とVGWとVIFのまとめ](https://qiita.com/mmurm/items/abf390def0ae6dbd1950)
[占有型？共有型？AWS Direct Connect の接続（Connection）と仮想インターフェース（VIF）関連の用語を整理してみた](https://dev.classmethod.jp/articles/aws-direct-connect-connection-vif-organize-terms/)
[AWS Transit Gatewayとは？概要や利用するメリットについて説明します](https://atbex.attokyo.co.jp/blog/detail/96/)
[ネットワークエンジニアが教える！AWSのVPCルーターの全て](https://koejima.com/archives/1950/)

[EC2 WindowsインスタンスにCloudWatchエージェントをインストールして稼働させる](https://dev.classmethod.jp/articles/launch-cwagent-on-ec2-windows-instances/)
[AWS_CloudWatchとCloudTrailの違い　#401](https://note.com/ym202110/n/nc22c5d68c924)
[CloudWatch(Logs)とCloudTrailについて](https://www.acrovision.jp/service/aws/?p=2222)
[CloudWatchAgentAdminPolicyとCloudWatchAgentServerPolicyの違いを調べた](https://qiita.com/curlneko/items/f38533e7f949e7f6456b)
[[AWS]CloudwatchエージェントをRunCommandのみでインストールする](https://qiita.com/Nacht/items/82145082cb96c6abeeff)
[ウィザードを使用して CloudWatch エージェント設定ファイルを作成する](https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/create-cloudwatch-agent-configuration-file-wizard.html)
[サーバーで CloudWatch エージェントをインストールおよび実行する](https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/install-CloudWatch-Agent-commandline-fleet.html)
[Amazon CloudWatch Logs でログを読むための手法メモ](https://qiita.com/Shigai/items/8739f5f0fa524433aabe)
[VPCフローログの取得方法（CloudWatch Logsに保存）](https://qiita.com/kerorinfather/items/64c3ca83017e521d9917)

[【保存版】AWSリソース名の決め方と命名規則](https://zenn.dev/kaoru_dev/articles/df589681a31320)
[プロプライエタリシステム](https://e-words.jp/w/%E3%83%97%E3%83%AD%E3%83%97%E3%83%A9%E3%82%A4%E3%82%A8%E3%82%BF%E3%83%AA%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0.html)
[【3分理解】Linuxディストリビューションの確認方法](https://eng-entrance.com/linux-distribution-check)

[SOCとは？必要性や他のセキュリティとの違い・構築方法を解説](https://www.menlosecurity.com/ja-jp/blog/soc)
[SOC（Security Operation Center）とは](https://www.ntt.com/bizon/glossary/e-s/soc.html?msockid=36dd928986126d7e3042815087686cc0)
[SIEMとは？意味や特徴・メリットをわかりやすく解説](https://cybersecurity-jp.com/column/33591)