AWSセキュリティ

1.AWSのセキュリティについて

1.1 はじめに

(1)責任共有モデル

・AWSは、クラウドのセキュリティに対する責任を持つ。
・顧客は、クラウド内のセキュリティに対する責任を持つ。
https://aws.amazon.com/jp/compliance/shared-responsibility-model/
情報処理安全確保支援士の過去問（平成24年春SC午後Ⅱ問2）には、以下の図があります。

d　事業者 、e　自社　

(2)AWSのセキュリティソリューション

大項目だと、以下になります。
・アイデンティティとアクセス管理
・発見的統制
・インフラストラクチャ保護
・データ保護
・インシデント対応

図の出典：https://aws.amazon.com/jp/blogs/news/jpmne-aligning-aws-security-services-to-movielabs-common-security-architecture-for-production-csap/

(3)予防的統制と発見的統制

統制	内容	サービス例
予防的統制	ルール違反をさせないために適用する。	IAM、Organizations、データ保管時の暗号化、ControlTower、サービスコントロールポリシー (SCPs）の組み合わせ、など
発見的統制	ルールに違反している場合に通知	CloudTrail、Amazon GuardDuty、CloudWatch、AWS Security Hub、AWS Configなど

・「予防的統制」や「発見的統制」として利用しているサービスのアンケート結果は以下にあります。
https://drive.google.com/file/d/1P3AXxZo0BIw4DSsDc40Rp4Yqa3AmuHRd/view
・たとえば、p60に、「発見的統制」として使っているAWSサービスのアンケート結果があります。大規模の場合、CloudTrailログが81%、GuardDutyが59%、CloudWatchが62%が上位です。

・p65には、「インフラストラクチャ保護」として、「VPCサブネットで、PublicサブネットとPrivateサブネットを使い分け」が86.49%、「特定のネットワークからのみ接続を許可」が78.38%、「IAMポリシーやバケットポリシーなどのリソースレベルでアクセス制御　48.65%、「AWS WAF」が48.65%です。AWS Shield Advancedは2.70%と少ない。

(4)ガードレール

AWSのセキュリティ対策の考え方の一つにガードレールがある
https://blog.takuros.net/entry/2020/07/03/085926

1.2 AWSへのアクセス方法

さすがAWSさんの資料。わかりやすい。つまり、2系統ある。
1)ID/PWを使ってマネージメントコンソール（GUI）画面からログインする。こちらは二要素認証の設定が可能
2)アクセスキーとシークレットアクセスキーを用いて、AWS CLIで接続する。

1.3 無料で利用できるもの

・IAM
・AWS ShieldによるDDoS対策（一定程度の簡易な防御）。有償版もあり
・ネットワーク系の通信の防御
　－NetworkACLやSecurityGroupによる防御
・Multi-Factor Authentication (MFA)
・AWS Organizations
・AWS CloudTrail（基本的な部分のみ）

1.4 デフォルトで対応されているもの

❶25番ポートの遮断
AWS上のインスタンスにメールサーバを勝手に構築し、メールを送ることができません。いわゆるSPAM対策です。厳密には違いますが、OP25Bが設定されていると考えてください。（OP25Bは動的IPの場合に限定です）。逆にプライベートIPは許可されていて、ダイレクトコネクトなどでオンプレのサーバからは制限されていません。
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ec2-resource-limits.html#port-25-throttle
25番ポートを解放するには、AWSサポートに申請します。
また、メールを送るサービスであるAmazon SESが推奨されています。

❷AWS ShieldによるDDoS攻撃
デフォルトで防御されています。

1.5 最低限実施したい対策

(1)AWSの機能を使うもの

・CloudTrail（インスタンスを起動したなどの操作ログの取得）、Config（ルートユーザのMFAが無効になっている。ポートが全て空いているなどチェック）などの監査ログの取得
・Inspectorによる脆弱性診断
・コンプライアンスポリシーへの準拠を厳密にチェックされる自治体などにおいては、GuardDutyやSecurityHub
・IAMポリシーなどのリソースレベルでアクセス制御
AWSで実施したいセキュリティ対策とは？
https://www.lanscope.jp/blogs/cloud_security_pfs_blog/20231228_17806/

以下に結構まとまっています。
https://sysdig.jp/blog/26-aws-security-best-practices/

(2)AWS以外の機能や設定

Q.サードパーティのウイルス対策ソフトは必要？

A.リアルタイムスキャンはAmazon GuardDuty Malware Protectionでは行えない。スナップショットから検知するため。よって、TrendのCloud Oneを入れるといいかも。
https://www.trendmicro.com/ja_jp/business/campaigns/aws/column/guarddutymalwareprotection.html
Linuxサーバにはマルウェア対策ソフト入れないことも多いので、実質的に入れないことも多いかもしれませんが・・・。

(3)rootユーザーに対して

・ルートアカウントの MFA 有効化
・アクセスキーの削除
（・パスワードポリシーの強化）←MFAが適切であれば、それほど重要ではないかも

(4)参考：アクセスキー

AWSにログインするには、ユーザを作成して管理コンソールからログインする方法以外に、アクセスキーを使う方法があります。アクセスキーとシークレットアクセスキーがあればログインできてしまうため、管理は慎重にしなければいけません。
アクセスキーの管理は、右上のユーザの名前からプルダウンで「セキュリティ認証情報」の「アクセスキー」でアクセスキーの状態を把握し、不要なアクセスキーは削除しましょう。

また、アクセスキーを用いた場合、どんな権限があるかというと、このIAMユーザに割り当てられているポリシーとロールが適用されます。なので、rootユーザであれば、全部の権限があります。
それと、現実的かどうかはさておき、2要素認証もできます。ただ、CLIでスクリプトで処理を実行させる場合にアクセスキーを用いられると思いますが、それこでMFAというのは現実的ではない気がします。
https://www.secure-iv.co.jp/blog/12393

1.6 参考：農水省のMAFFクラウド

農水省ですが、ガバクラを独自開発し、MAFFクラウドを運用しています。
仕組みについては以下に公開されています。
https://japan.zdnet.com/article/35203354/

上記に記載がありますが、MAFFクラウドの場合、以下の4つをセキュリティ面の共通機能とし利用しているとあります。

	機能	概要
1	AWS Direct Connect	専用線接続
2	Amazon GuardDuty	不正アクセスや悪意のある挙動を検出
3	AWS Config	ルートユーザのMFAが無効になっている。ポートが全て空いているなどチェック、変更のログの取得
4	AWS Security HUB	Configによる各リソースの診断結果をまとめ、全体として準拠性を満たしているかのチェック

2.具体的なセキュリティ機能❶ユーザおよびアクセス権

2.1 IAM

AWSのIAM(Identity and Access Management)により、ユーザやロール、ポリシーの管理を行う。

(1)概要

・IAM（Identity and Access Management）を直訳すると、Identity（身分）とアクセス権限の管理
・AWSのルートユーザ以外にユーザを作る場合はIAMユーザを作成する。
・ユーザの管理とパスワード変更、二要素認証などを行う。
・IPアドレスでの接続制限も可能
・これを使うと、複数人でAWSのインスタンスをセキュリティを保って管理ができる。

用語	説明
IAM（アイアム）ユーザ	AWSの操作をするユーザ。上限5000個
IAMグループ	IAMユーザをグループ化する。上限100

(2)アクション

・AWSの各サービスやリソースに対する各種の操作（追加、変更、削除など）のことです。
・一つのポリシーは、複数のアクションから成り立っています。
・IAMポリシーで指定できるアクションは、各AWSサービスが提供するAPI操作として定義されており、ユーザーが独自に新しいアクションを作成することはできません。つまり、利用可能なアクションはAWSによってあらかじめ決められているものから選択する形になります。

(3)ポリシー

・ポリシーは、アクションをグループ化したもの。デフォルトはAWSがいくつも用意してありますが、個別に作成も可能です。
・一つのユーザやロールには複数のポリシーを割り当てることができる
・IAMでデフォルトで作成されているAmazonEC2ReadOnlyAccessをみてみましょう。
内容はJSON形式で確認できますが、Actionとして、"ec2:Describe*"や "ec2:GetSecurityGroupsForVpc"などが定義されていることがわかります。

(4)ロール

・AWSの定義によると、「IAM ロールは、特定の許可があり、アカウントで作成できるもう 1 つの IAM アイデンティティ」です。アイデンティティという言葉がわかりづらいですが、IAMユーザーがユーザの関するもので、IAMロールはインスタンスなどの資源に関するものです。
・たとえば、S3などのストレージは、ユーザが接続する場合もあれば、他のシステムやAWSのサービスが利用する場合もあります。ユーザを定義するのがIAMユーザで、該当する資源へのアクセス権を設定するのがロールです。なので、あるシステムからのログをS3のバケットに出力しようとすると、ユーザを割り当てずにロールを割り当てることが一般的です。もちろん、S3にアクセスできるユーザを作成し、アクセスキーとシークレットアクセスキーを用いて認証して接続することも可能ですが、システムに権限を割り当てた方が便利です。
・IAMユーザもIAMロールも、どちらも複数のアクションからなるポリシーを割り当てることができる。

・ロールを作成すると、以下のように対応付ける資源を選定できます。
・一つのロールに複数のポリシーを割り当てることができる

(5)割り当ての例

項番	シナリオ	IAMユーザ	IAMロール	アクション例	ポリシー例	設定内容の例
1	ユーザにログイン権限とEC2の権限を割り当て	IAMユーザ ※コンソールログイン用の認証情報（パスワード、MFAなど）も設定	-	・EC2関連 API 操作（例: ec2:DescribeInstances、ec2:StartInstances、ec2:StopInstances 等）	・AWS管理ポリシー「AmazonEC2FullAccess」または必要な操作に絞ったカスタムポリシー ※コンソールログイン自体はIAMユーザの設定で有効化	IAMユーザを作成し、コンソールログイン用の認証情報を設定。 該当ユーザにEC2操作を許可するポリシーをアタッチ
2	ユーザにS3バケットへのアクセス権を割り当て	IAMユーザ ※コンソールログインまたはプログラムからのアクセス	-	・S3関連操作（例: s3:ListBucket、s3:GetObject、s3:PutObject 等）	・AWS管理ポリシー「AmazonS3FullAccess」または用途に合わせたカスタムポリシー	IAMユーザを作成し、必要に応じた認証情報を設定。 S3へのアクセスを許可するポリシーをアタッチ
3	EC2インスタンスにS3バケットへのアクセス権を割り当て（例：ログ保管用）	-	IAMロール ※EC2インスタンスに紐付ける形で利用	・S3関連操作（例: s3:PutObject、s3:ListBucket、s3:GetBucketLocation 等）	・AWS管理ポリシー 「AmazonS3FullAccess」または用途に合わせたカスタムポリシー	IAMロールを作成し、信頼ポリシーで「ec2.amazonaws.com」からの引き受けを許可。 該当ロールにS3アクセス権を付与するポリシーをアタッチし、EC2インスタンスにロールを割り当て

ロールは、ユーザ以外のエンティティ（例：他サービス、外部システム、AWS のサービス自体）が一時的に権限を引き受けるための仕組みです。
ケース 1 や 2 のように、特定のユーザやグループに直接権限を割り当てる場合はロールは使いません。
ケース 3 のように、インスタンスから接続させる場合は、ロールを作成してポリシーをアタッチし、該当システムにそのロールを引き受けさせることで安全なアクセスを実現します。

(6)多要素認証

・特にルートユーザに関しては、認証を強化する必要があります。以下、ログインには、ルートユーザとIAMユーザの2種類がある。

AWSが用意している多要素認証は、以下があります。
　・パスキーまたはセキュリティキー
　・認証アプリケーション
　・ハードウェア TOTP トークン

↑は、ルートユーザでログインし、右上の自分のログイン名をクリックして「セキュリティ認証情報」>「多要素認証 (MFA) 」から表示できます。

(7)設定の流れ

・IAMユーザを作成し、IAMグループに所属させる。
・IAMグループにはIAMポリシーを設定する。
❶ポリシーの作成
ChatGPTに作ってもらった。指令は以下

AWSのIAMでポリシーを作成したいです。東京リージョンのEC2とVPCの全ての権限を付与する方法を教えてください。

作成されたJSONは以下です。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:*"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:RequestedRegion": "ap-northeast-1"
                }
            }
        }
    ]
}

以下、解説

要素	説明
Version	IAMポリシーのバージョン。2012-10-17が最新
Statement	この中に条件として、EffectやActionなどを記載
Effect	動作として、AllowかDenyを指定
Action	アクセス制御の対象となるリソースを指定
Resource	リソースを詳細に指定

ただし、最初は間違っていた。「vpc:*」というところでエラーが出たので、ふたたびChatGPTに聞いたら、「vpc:*というアクションは存在しません。VPCはEC2サービスの一部として管理されているため、VPCに関する操作もec2アクションで管理されます。」という。つまり、EC2を許可するとVPCも許可されるのだ。
これを、新しいポリシー「tokyo_ec2_vpc」として作成します。
a)IAM > アクセス管理 >　ポリシーから「ポリシーの作成」ボタンを押す。
b)「アクセス許可を指定」の画面になったら、「JSON」のタブに切り替える。
c)上記のJSONを貼り付けて、「次へ」

d)ポリシー名「tokyo_ec2_vpc」を付けて、「ポリシーの作成」ボタンを押して完成。

❷IAMユーザの作成
a)IAM > アクセス管理 >　ユーザ　から「ユーザーの作成」ボタンを押す
b)ユーザ名を入れて、「AWS マネジメントコンソールへのユーザーアクセスを提供する 」のチェックボックスにチェックを入れます。
ようは、CLIやAPIなどのコマンドで連携するのではなく、AWSのGUI画面にログインさせるという意味です。
なので、その下にあるパスワードの設定が必要です。

※今回は、パスワードをこちらで指定しました。
c)「許可を設定」で、「ポリシーを直接アタッチする」から、許可ポリシーで作成した「tokyo_ec2_vpc」を割り当てます。

d)「ユーザーの作成」ボタンで作成が完了。すると、メッセージとともに、そのユーザがログインするURLも表示される。

❸IAMユーザでログイン
上記で作成されたURLに接続して、設定したIDとPWでログイン。

東京以外のリージョンに切り替えると、以下のようにエラーが出る。なので、権限が無い。

・CloudFrontなどのサービスも利用できない

・Cloudwatchが使えないので、アラートのところは赤でエラーになっている

・ただ、VPCなどは、EC2に関連するサービスということで、自由に利用できそうだ。

❹IAMグループにポリシーを割りあて
a)ユーザを作成する
単にユーザを作るだけのだけの場合、「許可のオプション」で、「ユーザーをグループに追加」を選択
b)グループを作り、そこにユーザを割り当て、ポリシーも割り当てることが可能

❺IAMユーザの認証強化
1)パスワード変更
右上のユーザのボタンみたいなところから、「セキュリティ認証情報」

[コンソールサインイン」「コンソールパスワードの更新」よりパスワードの変更

2)MFAの設定
多要素認証 (MFA)>MFA デバイスの割り当て

(8)送信元IPアドレスによるログイン制限

具体的な方法は以下に記載があります。
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_policies_examples_aws_deny-ip.html
先ほどのユーザに、上記を参考に、以下のポリシーip_addres_strictを作成

{
    "Version": "2012-10-17",
    "Statement": {
        "Effect": "Deny",
        "Action": "*",
        "Resource": "*",
        "Condition": {
            "NotIpAddress": {
                "aws:SourceIp": [
                    "153.239.234.0/24",
                    "203.0.113.0/24"
                ]
            }
        }
    }
}

・ユーザに追加

・送信元IPが 153.239.234.0/24の範囲はログインできるが、それ以外の場合、以下のようにログインはできてもEC2のインスタンスに接続できない。作成もできない。ログインそのものを制限することはできない。ログイン後のAPIをIPアドレスで制限しているので、こんな画面になります。

2.2 セキュリティグループ

(1)機能概要

・仮想ファイアウォール機能として、FWと同様に、送信元IPアドレスやプロトコル、ポート番号などで通信を制御できる（制御といっても、厳密には通信の許可のみ）

・セキュリティグループは、インスタンス単位ではなく、インターフェース単位で、インターフェースに適用される。一つのインスタンスに複数のIFが存在するときもあり、それぞれのIFに対して、インバウンドやアウトバウンドの通信の制御が必要。
・セキュリティグループは、静的フィルタではなく、動的フィルタ（ステートフルインスペクション）なので、戻りのパケットは自動で許可される。
・ルールはホワイトリストで、許可するルールが記載される。複数のセキュリティグループを適用すると、すべてのルールがAND条件で許可される。

(2)AWSでセキュリティグループの変更

ネットワーク&セキュリティ＞ネットワークインターフェース　から該当するIF(基本はインスタンスのeth0)を選び、アクションからセキュリティグループの変更

(3)セキュリティグループの名前を変更

あとからはできない。新規に作成して、割り当てを変えるしかない。

(4)LinuxインスタンスにおけるFirewall機能

AWSだと、firewalldそのものが入っていない（以下）。AWSにおいては、FW機能はセキュリティグループで設定するようにということであろう。

# rpm -q firewalld
package firewalld is not installed

2.3 Organizations

AWS Organizationsでは、マルチアカウントの一元管理をし、ポリシーや課金を統合する仕組みです。

(1)概要

・以下の統計データがありますが、「予防的統制」として、半数程度の組織がAWSのOrganizationsを用いてAWSアカウントを作成しています。
https://drive.google.com/file/d/1P3AXxZo0BIw4DSsDc40Rp4Yqa3AmuHRd/view

・OUを作成してルールを作れるので、たとえばアメリカのリージョンではインスタンスを作成できないなどの統一ルールを作れます。
・サービスコントロールポリシー (SCPs）は、アカウントやOUに対して操作を制御するポリシーです。詳しくは後述します。
https://docs.aws.amazon.com/ja_jp/organizations/latest/userguide/orgs_manage_policies_scps.html
・AWS Organizationsを導入するには、以下を検討します。
　a)アカウント（管理アカウント、メンバーアカウント）
　b)組織単位 (OU)
　c)サービスコントロールポリシー (SCP)

(2)導入するメリット

❶一元的な管理
　すべてのAWSアカウントを一つのグループにまとめて管理ができる。
❷コストの最適化
　統合請求 (Consolidated Billing) により全アカウントのコストをまとめて把握可能。※アカウントごとに確認するのは大変
❸一元的なポリシー適用
サービスコントロールポリシー (SCP) によって、アカウントや組織単位 (OU) に対して一元的なポリシー適用ができる。たとえば、特定リージョンのみ利用を許可・禁止、EC2とS3以外のサービス利用を禁止、EC2で特定のインスタンスタイプに制限するなどが設定できます。

(3)アカウントについて

AWS Organizationsのアカウントは、管理アカウント (Management Account)とメンバーアカウント(Member Account)があります。
❶管理アカウント (Management Account)
　Organizationsを作成するには、1つの「管理アカウント」が必要です。
このアカウントは、Organizations全体を管理するものです。もちろん、管理アカウントでも、インスタンスを起動したりVPCを作ったりできますが、実際の運用作業は、管理アカウントで実施しないことが推奨です。
また、Organizations内のすべてのアカウントの請求が管理アカウントに集約されます。
❷メンバーアカウント(Member Account)
　実際に運用するアカウントです。
　新規に AWS Organizationsを構成する場合は、既存のアカウントをAWS Organizationsに移行することになります。その手順は、管理アカウントから既存アカウント (A, B, C) に招待を送ります。各アカウントは、招待を承認します。すると、A, B, Cは「メンバーアカウント」としてOrganizationsの一部になります。
メンバーアカウントは、SCPが設定されていると、その制約を受けることになります。

(4)OU

OU（Organizational Unit）は、組織単位という言葉の通り、組織や役割単位で作成することが基本です。たとえば、開発環境、本番環境であったり、営業部や開発部などの組織ごとにOUを作り、そのOUにSCPを割り当て、アクセス制御をすることができます。

(5)SCP

・Organizationsのデフォルト設定では、「FullAWSAccess」というSCPが適用されており、全サービスが許可されています。
・SCPは以下の単位で適用できます。

❶	OUに適用	OUに所属するすべてのアカウントにSCPを適用します。たとえば、開発環境OUでは、大規模なインスタンスタイプを作成禁止など。
❷	特定のアカウントに適用	OUではなく特定のアカウント単位でSCPを適用可能です。ただし、OUに適用されたSCPの制約は引き続き有効です。
❸	ルート組織に適用	組織全体に適用されるポリシーを作成可能できます。たとえば、○○のリージョンでのインスタンスを起動を禁止するなど。

・SCPの例として、 米国リージョン（us-east-1、us-west-2）以外でのリソース作成を禁止する場合は以下です。

{
  "Effect": "Deny",
  "Action": "*",
  "Resource": "*",
  "Condition": {
    "StringNotEquals": {
      "aws:RequestedRegion": ["us-east-1", "us-west-2"]
    }
  }
}

・SCPによる制限例は以下です。

項目	制限例
利用リージョン	操作可能な地域を制限
利用サービス	許可または禁止するサービスを制御
リソースタイプ	特定のリソース作成や変更を禁止
セキュリティ	MFAやルートユーザーの制御、IAM制限
コスト管理	高コストリソースやAWS Marketplace利用の制限
ネットワーク	IPアドレスやVPC条件での制御
運用効率	時間帯やタグベースの制御

(6)操作

AWS Organizationsを開きます。

・右上にある「AWSアカウントを追加」することで、アカウントを追加します。
・または、「招待」タブから、既存のアカウントを招待して、組織内に追加することもできます。

・OUの作成
　Rootにチェックを入れ、アクション>新規作成　でOUを作成します。

2.4 ControlTower

https://qiita.com/kaburagi_/items/521c1143dcae674ae490
何ができるかというと、大きく2つ（だと思う。）
1)安全なマルチアカウント AWS 環境のセットアップと管理　
https://aws.amazon.com/jp/controltower/
→セットアップの自動化ができる。
2)AWS Control Towerでは、ログアーカイブアカウントログを集約可能。

★以下も参照
https://blog.takuros.net/entry/2020/07/03/085926

3.具体的なセキュリティ機能❷監視およびログの保存

3.1 GuardDuty（ガードデューティ）

(1)概要

・フルマネージド型の「脅威検出サービス」です。IDSと考えてもいいでしょう。ただし、防御機能はないので、IPSではありません。

機械学習を活用し、APIコールや通信ログを監視して不正アクセスや悪意のある挙動を検出します。複雑な設定やインストールなどの手間はなく、AWS上で「有効化」するだけで利用できます。公式では、サポートされているすべてのリージョンでAmazon GuardDutyの有効化を推奨しています。（https://www.lanscope.jp/blogs/cloud_security_pfs_blog/20231228_17806/より

・CloudTrail等のログと連携した不正アクティビティの検知
・GuardDuty有効化から無効化まで
https://qiita.com/emiki/items/17b4df4618798cacdac8
・リージョンサービスなので、リージョンごとに設定
・脅威インテリジェンスは、Proofpoint や CrowdStrikeなどの情報を利用

GuardDutyの脅威インテリジェンスは、AWSとProofpoint や CrowdStrike などのサードパーティープロバイダによって提供されます。（出典：https://aws.amazon.com/jp/guardduty/faqs/）

・VPC Flow Log、DNSログ、CloudTrailEvent、S3Data Eventsを受け取り、怪しいかどうかを判断する。これらのログの取得は、GuardDutyをONにすると、裏で自動で取得してくれる。
たとえば、portScan　悪意のあるIPや、不正なポートへの、ブルートフォース攻撃
　ただ、検知だけでブロックはできないので、CloudWatchなどを連携する必要がある。
・GuardDutyを有効化するためには、他のCloudTrailなどの設定は不要です。AWSのGuardDutyが勝手にやってくれます。

(2)WAFとの違いは？

・従来のIDS（GuardDuty）とWAFの違いと考えてもらってもいいでしょう。
・WAFはインスタンスより外側で検知する。また、レイヤがレイヤ７のアプリケーションレベルが主。
・GuardDutyは、インスタンスに届いたパケットなどAWSの内部のトラフィックを分析する。
・GuardDutyは検知だけあるが、WAFはブロック機能も持つ

(3)調査対象のログ

GuardDutyは、基本機能として以下のログを調査対象としていて、それ以外のログは見ない。

調査対象	説明	例・検出されるパターン
AWS CloudTrail ログ	AWS API の呼び出しに関するログ。管理イベントやデータイベントを解析し、不正アクセスや異常な操作パターンを検出。	異常な API 呼び出し、認証情報の不正利用、権限昇格の試み
VPC Flow Logs	VPC 内のネットワークトラフィック情報。通信パターンの異常や不正なデータ送信、外部への不審な接続を検知。	不審なアウトバウンド通信、ポートスキャン、内部からの大量データ送信
DNS ログ	DNS クエリのログ情報。悪意あるドメインへのアクセスやマルウェアのコマンド・アンド・コントロール（C2）通信などを検出。	悪意のあるドメインへの問い合わせ、不審なDNSリクエストパターン
脅威インテリジェンス	AWS やサードパーティから提供される脅威インテリジェンスフィードと照合することで、既知の悪意あるIPアドレスやドメインとの通信を特定。	悪意のあるIPアドレスやドメインとの通信、既知のマルウェア関連通信の兆候

※これは基本機能の話であり、追加の機能は別

(4)検出結果の確認方法

1)GuardDutyコンソール
GuardDutyの管理画面にて、検知結果（Findings）が一覧で確認できます。ただし、VPC Flow Logsなどの生ログは、確認できません。
2)CloudTrailの画面

(5)管理者への通知方法

GuardDutyの検知結果は、EventBridge（旧称CloudWatch Events）にイベントとして送信されるため、このイベントをトリガーとして通知を行う仕組みが利用できます。たとえば、検知結果発生時にAmazon SNSに通知を送ることで、自動でメールによる通知ができます。

(6)設定

・リージョンを選択した上で、GuarDutyを開く

・「今すぐ始める」を押して、「GuarDutyを有効にする」を押す

・「GuardDutyを有効にする」と有効になります。設定の画面から、「GuardDuty を一時停止」や「GuardDuty を無効にする」ことも可能です。

(7)追加の保護プラン

・基本機能として、先に述べたVPC Flow Logs、DNS Logsなどを見て、不審なネットワークアクセス、権限の濫用などを検出します。それ以外に、追加の保護プラン（オプションが）があるので、必要に応じて選択します。
・料金的にはそれほど高額にはならないので、必要なものは有効にしておくのがいいでしょう。
・いくつかあり、年々アップデートされている。

プラン名	対象リソース	内容
EKS Protection	Amazon EKS（Kubernetes）	EKSのAPI操作ログを分析し、異常な操作を検出
S3 Protection	Amazon S3	S3のデータアクセス（GetObjectなど）を監視
Runtime Monitoring	EC2/ECS	ランタイム中の挙動を検査（プロセス、ネットワークなど）
Malware Protection for EC2 – 実行型スキャン	EC2	GuardDutyが自動的にEBSスナップショットを取りマルウェアスキャン
Malware Protection for EC2 – オンデマンドスキャン	EC2	ユーザ操作でオンデマンドにマルウェアスキャンを実行可能
Malware Protection for S3	S3（バケット内オブジェクト）	S3にアップロードされたファイルを対象にマルウェア検査
RDS Protection	Amazon RDS	RDSデータベースのログを分析して不正なクエリや侵害を検出
Lambda Protection	AWS Lambda	Lambda関数の実行中挙動（呼び出し元や実行内容）を監視

※Kubernetesは、コンテナ化されたアプリケーションを自動でデプロイ・スケーリング・管理するためのオープンソースのオーケストレーションツールです。複数のサーバで効率的に動作させることができます。Kubernetesをフルマネージドで利用できるサービスがAmazon EKSです。

(8)GuardDuty Runtime Monitoring

https://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/runtime-monitoring.html
完全リアルタイムではなくても、リアルタイムに近い検知ができる。
ファイルレスも検知できるというが、どこまでできるかは要調査。

(9)Amazon GuardDuty Malware Protection

リアルタイムスキャンはAmazon GuardDuty Malware Protectionでは行えない。スナップショットから検知するため。
【参考】Amazon GuardDuty Malware ProtectionとTrend Cloud Oneの違い
https://www.trendmicro.com/ja_jp/business/campaigns/aws/column/guarddutymalwareprotection.html

3.3 CloudTrail

(1)概要

・AWSのアカウントによる、「いつ」「誰が」「何」をしたかの操作のログを取ります。
・AWSの操作などに関して、基本的にはほぼすべての操作がAPIによる呼び出しで行われます。たとえば、AWSのマネジメントコンソールにログインして、EC2を起動するのもRunInstancesのAPIによって起動します。CloudTrailでは、そのログを取ります。たとえば、インスタンスに関しては、RunInstances、StopInstances、StartInstances、TerminateInstancesなどのAPIがある。
・ただし、インスタンスの中で起こっているログインなどイベントは残らない。なので、OS側のログで確認する必要がある。
・操作としては、AWSのマネジメントコンソール（GUI画面）、CLI、SDK、他のサービスからの操作のログ。
・CloudTrailは管理イベントに関しては、デフォルトで有効で、90日間のログを取っている。また、データの操作やインサイト（7日間のベースラインでの異常なアクティビティ）、ネットワークアクティビティに関しては、設定が必要★
・90日以上のログを保存するには、S3を活用する。Cloud Watch Logsと連携可能。
・リージョンサービス

(2)CloudTrailを有効化しない場合

❶取得できるログについて
・AWS CloudTrailは、証跡（Trail）を設定しなくても、デフォルトで直近90日間の管理イベント（Management Events）を自動的に取得し、AWSマネジメントコンソールで閲覧できます。※なので、有効にしなくても最低限のログは取得される。
・これはイベント履歴（Event History）として提供されるもの。
・デフォルトで取得されるログの例は以下。

項番	取得するログ	具体例
1	AWSマネジメントコンソールでの操作	・ユーザーがEC2インスタンスを起動 (RunInstances) ・IAMユーザーを作成 (CreateUser)
2	AWS CLIやSDKによるAPIコール	・AWS CLIでS3バケットを作成 (CreateBucket) ・AWS SDKでLambda関数をデプロイ (CreateFunction)
3	認証・認可に関する操作	・IAMポリシーの変更 (AttachUserPolicy) ・MFA設定の変更 (DeactivateMFADevice)

・ログとしては最低限であり、必要に応じて追加する必要があるのと、保存期間が90日しかない。
❷CloudTrailを有効化しない場合の制約
・90日間のみ閲覧可能　→それ以上のログを保持したい場合は、証跡を作成してS3に保存する必要がある。
・デフォルトではCloudWatch Logsに送信されない　→　CloudWatch Logsを使ってリアルタイム監視ができない
・取得するログが限定的　→たとえば、データイベント（S3やLambdaのアクセスログ）は取得されない

(3)イベントの全体像

種類	説明	料金	具体例
管理イベント	AWSリソースの作成・変更・削除などの操作を記録	無料（最初の1つの証跡のみ）	`RunInstances`,`CreateUser`, `DeleteBucket`
データイベント	S3オブジェクトやLambda関数の実行などのデータ操作を記録	有料（$0.10/100,000件）	`GetObject`,`PutObject`, `InvokeFunction`
インサイトイベント（InsightsEvents）	通常と異なるAPI使用パターンを記録	有料（$0.35/100,000件）	異常なAPIリクエストの急増

(4)管理イベント（ManagementEvents）の例

・AWSのリソースの作成・変更・削除など、管理レベルの操作を記録するイベント。

カテゴリ	具体例
IAM操作	`CreateUser`,`DeleteUser`,`AttachUserPolicy`
EC2管理	`RunInstances`,`StopInstances`,`TerminateInstances`
S3管理	`CreateBucket`,`DeleteBucket`,`PutBucketPolicy`
Lambda管理	`CreateFunction`,`UpdateFunctionConfiguration`
RDS管理	`CreateDBInstance`,`DeleteDBInstance`,`ModifyDBInstance`
VPC管理	`CreateVpc`,`DeleteVpc`,`AuthorizeSecurityGroupIngress`

・ログは非常に多岐にわたる。たとえば、「instance」で検索しても、以下のように、インスタンスを起動（StartInstance）、停止（StopInstance）などを含め、たくさんある。

(5)データイベント（DataEvents）

AWSサービスのデータアクセス（例:S3のオブジェクト取得、Lambdaの関数実行）を記録するイベント。デフォルトでは無効で、明示的に有効化する必要がある。

AWSサービス	具体例
S3（オブジェクトレベルの操作）	`GetObject`,`PutObject`,`DeleteObject`
Lambda（関数の実行）	`InvokeFunction`
DynamoDB（データ操作）	`PutItem`,`GetItem`,`DeleteItem`

(6)料金

・デフォルトで取得される90日間のログは無料
・90日以上はS3に保存するので、S3の料金が必要
・アラートを設定する場合は、CloudWatchLogsの料金が必要
・管理イベントに関して、1つ目の証跡は無料。１つの証跡といっても、CreateUser、DeleteUserなど、30種類以上のイベントを取得することは可能。証跡のルールが1つと考えればいいだろう。
・データイベントやインサイトイベントは有料
・10万イベントあたり2ドルなどの費用がかかる。★本当？

(7)設定

a)AWS CloudTrailを開き、「証跡の作成」

b)名前を付けて「証跡の作成」

c)作成した証跡が表示される

d)上記において、名前のところをクリックすると、デフォルトの証跡の内容が確認できる。具体的には以下。

このように、管理イベントではAPIアクティビティの全てが記録され、データイベントやInsightsイベントは取得されていないことがわかる。

・CloudTrail > イベント履歴　にて、履歴を見ることができる。

3.4 VPC Flow Logs

(1)概要

・VPC内のトラフィックのログ（FlowLog）を取る。ENI単位で取得する。無料だが、取り込み先のS3の料金、またはCloudWatchの料金がかかる。

(2)設定

・VPCの中で、ログを取りたいVPCを選び、フローログのタブから「フローログの作成」

ただし、このときにIAMロールを割り当てる必要があるので、以下の手順で実施する。
https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/flow-logs-iam-role.html
以下のあたりの手順を実施する。

フローログの IAM ロールを作成するには
IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。
ナビゲーションペインで、ポリシー を選択します。
[ポリシーの作成] を選択します。
[ポリシーの作成] ページで、次の操作を行います。
[JSON] を選択します。
このウィンドウのコンテンツを、このセクションの冒頭にあるアクセス許可ポリシーに置き換えてください。
[Next] を選択します。
ポリシーの名前、説明 (省略可能)、タグを入力し、[ポリシーの作成] をクリックします。

・まず、ポリシーを作る

・先のマニュアルに記載のJSONをコピーしてポリシーを作成

・つづいて、ロールも同様。先のマニュアルに記載のJSONをコピーしてロールを作成。このとき、先のポリシーを適用する。
・これでフローログが作成できるので、作成していく。最大集約間隔は、普通は10分でいいが、すぐに見たい場合は1分間にする。

・保存先はCloudWatchにしておく。続きはCloudWatchにて。

3.5 SIEM on Amazon OpenSearch Service（OSS）

SIEMを使ったログ分析
https://www.tis.jp/special/platform_knowledge/cloud22/

4.具体的なセキュリティ機能❸セキュリティ診断（脆弱性管理）

4.1 Amazon Inspector

・ソフトウェア脆弱性が無いか、意図していない情報が公開されていないかなどの脆弱性診断を自動でやってくれるサービス
・ただ、内容はそれほど本格的では無いように感じた。
https://www.wafcharm.com/blog/amazon-inspector-for-beginners/
・もちろん、AWS配下のサーバしかスキャンはできない。他のシステムも含めて一元管理したいのであれば、TenableとかFuture Vulsなどを使う必要がある
・以下の3つがスキャン対象
　1)Amazon EC2インスタンス：パッケージの脆弱性、ネットワーク到達可能性（ポートスキャンではなく、セキュリティグループなどの設定を見て判断している）
　2)Amazon ECRコンテナイメージ：ECR はフルマネージド Docker コンテナ
　3)AWS Lambda関数：パッケージの脆弱性、コードの脆弱性

・インスタンスへのエージェント（AWS Systems Manager ：SSM←スペルが一致していませんが) が必要 →EC2の場合、最近のインスタンスであればデフォルトで入っています。
・エージェントレスのスキャンも可能。その場合、EBSのスナップショットがスキャンされる。スナップショットだと、動いているプロセスとかがわからないし、yumとかapt実行できないので、検査精度は理論的には落ちる可能性があるが、あくまでもCVEに関する脆弱性のスキャンと考えると、あまり差はないのではないか。もちろん、リアルタイム性の面では、エージントレススキャンは劣る。
https://dev.classmethod.jp/articles/amazon-inspector-agentless-assessments-ec2-ga/
・Inspectorスコアは、CVSSスコアを基に算出される。結果は、5段階（Cirtical、High、Medium、Low、Info）に分類される。
・CVE番号を含む脆弱性を把握しているので、脆弱性スキャンはやりやすいですよね。ただし、万能ではない。たとえば、RPMじゃなくソースコードからコンパイルしたものは検知できないし、 detection platform（以下）にないOSも検出されません。

・Inspectorでは検知後、対処方法もコマンド、記載してくれる
・Inspectorの管理画面は日本語化されているが、脆弱性の詳細は英語しかない。なので、Google等で別途調べる一手間が必要。
・場合によっては、追加の脆弱性管理も検討する必要がありそう。
・例えば、CTFdのインスタンスがあって、その問題にeicarファイルをUPloadしたとする。しばらくすると、Guard Dutyで検知する。

5.具体的なセキュリティ機能❹セキュリティ監査

5.1 AWS Config

(1)概要

・リソースの構成情報のログを取得
・設定内容と、あるべき姿の設定の差異を自動でチェックしてくれる。修正をすることも可能。
・設定変更を自動で追跡する。その変更が、あるべき姿と違うかをチェック。
・CISの準拠ルールに従うなどもできるが、実際にはAWS Security Hubで設定する。準拠性の確認には、まずログを取って、悪い設定に変更されないかなどの確認が必要なので、AWS Configが動作する必要がある。つまり、裏で動いている。
・ルールの例として、たとえば、ボリュームが暗号化されているか、パブリックから読み取りできるか、例は以下
https://docs.aws.amazon.com/ja_jp/config/latest/developerguide/managed-rules-by-aws-config.html
・Config：具体的にどんな設定変更が行われたかを確認する。
　ConfigRule：リソースの設定値がルールに沿っているかをチェックしたい場合に利用する。
・費用はルールの数によって変わる
https://dev.classmethod.jp/articles/recommend-config-rules-for-all-user/

ちなみに、CLIでVPCを作ったりできるaws configureとは別もの。

AWS ConfigはEC2、EBS、セキュリティグループ、VPCなどのAWSリソース(※)の設定を評価、監査、審査できるサービスです。AWSリソースの設定変更の記録を行い、その設定に対し問題がないか確認し、問題がある場合はメール通知や修正対応ができます。（出典：https://business.ntt-east.co.jp/content/cloudsolution/column-try-26.html）

(2)設定

・AWS Config を起動。※リージョンごとに設定できる。
・「今すぐ始める」で開始。

・設定を進める。

設定項目	内容	備考
記録戦略	全てのリースタイプか、特定に絞るか	デフォルトのすべてとした
記録頻度	継続的な記録か、日時記録	デフォルトの「継続的な記録」でいいだろう。変更のログをリアルタイムで受信する。
オーバーライド設定
IAMロール	ロールを作成するかどうか
配信方法	記録をどこに保存するか	デフォルトのS3バケットの作成にした

・AWS マネージド型ルール の選択
たとえば、「alb-waf-enabled」は、ALBを立てるなら、WAFを有効にしてほしい。なので、それを通知する。
「vpc-sg-open-only-to-authorized-ports」は、セキュリティグループに関する設定で、少しわかりづらいが、少なくとも0.0.0.0/0を許可してポート制限もしない場合に非準拠となる。
ルールを増やせばお金がかかるので、必要なものだけを設定する。何もチェックをいれなかったら、リソースの変更の履歴が取られる。
それ以外には、SecurityHUBで設定したものも有効になる。

(3)結果の確認

とりあえず結果の画面になるが、数分で結果が表示されるだろう（※以下はインスタンスが無いので、特に何も表示されていないが・・・）

・「準拠」がルールに適用していて、「非準拠」は赤で表示される。
・左のメニューのルールを見ると、ルールが確認できる。

5.2 AWS Security HUB

(1)概要

・不適切な設定を自動で検知できる。
・複数のログの集約して、アラート（一元管理）ができるので、可視性が高まっている（マルチリージョンも対応）。別に、GuardDutyと比べて、画面が見やすいわけではないみたい。
・準拠性の確認ができる。ただ、準拠性の確認には、まずログを取って、悪い設定に変更されないかなどの確認が必要なので、AWS Configが動作する必要がある。つまり、AWS Configの有効化が必須。
参考までに、以下がSecurity HUBの画面。以下にあるように、Configが有効になっている必要がある旨の記載がある。

・準拠性としては、以下の項目がある。

セキュリティ基準	概要
AWS 基礎セキュリティのベストプラクティス	AWSが定義したセキュリティベストプラクティスで、56のサービスと合計573のチェック項目
CIS AWS Foundations Benchmark	バージョンがv1.2.0/v1.4.0/v3.0.0とある。Center for Internet Security(CIS)が定義したもので、上記のAWSの基礎セキュリティのベストプラクティスと比べてIAMの項目が多め
PCI DSS	クレジットカード情報を保存する場合の基準
NIST SP 800-53	米国国立標準技術研究所 (NIST) のフレームワーク

・Question. SecurityHubとConfigの違いは？
→Answer
　・Config（「設定」という意味）は、リソースの設定情報を記録したり、ルールによって準拠状況をチェックするサービスです。
　・SecurityHubはセキュリティコンプライアンスの準拠をConfigルールの集合を用いてチェックするサービスです。
　・どう違うの？って感じですが、Config自体がリソースの設定を見てチェックして、SecuryHubはそのルールの集合をセキュリティ基準としてチェックします。

(2)設定

「AWS Security Hub」を開き、AWS Security Hub の有効化をする。

(3)結果の画面

・セキュリティ基準ごとに、適合率を判定し、セキュリティスコアが表示される。以下は12%と低い

・結果に対して、どう対処をすればいいかを説明してくれる
・関係がない項目に関しては、「コントロールを無効にする」という方法もある。が、注意しないと、重大なミスを見逃す可能性もある。

(4)コスト

・Cost Explolerにて、ディメンジョンを使用タイプ、サービスをSecurity Hubにすることで、コストを確認することができる。

6.具体的なセキュリティ機能❺攻撃の防御

6.1 AWS Shield

DDoS攻撃の対処。デフォルトで有効化されているが、AWS専属エンジニアの解析が必要な場合は有償のAWS Shield Advancedを利用する。
・無料は、Amazon CloudFrontとAmazon Route53への検知がメインだが、インスタンスのDoSも多少は有効
・無料はL3,L4レベルまで。Advancedを使うとL7までできそう。ただ、月額3000ドルくらいするから非常に高額。
・Advancedになると、しきい値のチューニングなどもできる。また、DDoS攻撃によって高額請求になった場合でも、調整をしてもらえるようです。

6.2 AWS WAF

・無料版と有料版がある
・SQL Database、 IPレピュテーションなどのルールセットがあり、それを適用する。
・AWSマネージドルールグループには以下がある

ルールグループ	概要
ベースライン	たとえば、SQLインジェクションの基本的な攻撃を防ぐのはここに含まれている
ユースケース固有
IP 評価ルールグループ

(3)料金

作成するACL、ACL ごとに作成する各ルールに対して請求される。さらに、Web ACL によって処理された Web リクエストの数に対して請求される。

課金の種類	料金
自ら作成したWeb ACL	月あたり USD 5.00
ルール	月あたり USD 1.00
リクエスト	USD 0.60/100 万件のリクエスト

料金例：お客様が作成した3つのWebACLと21のルール、3500万件のリクエスト
・Web ACL 料金の合計 = 5.00 USD × 3 = 15.00 USD
・ルールの料金 = 1.00 USD x (マネージドルールグループ 3 つ + ルール 21 件) = 24.00 USD
・リクエストの料金 = 0.60 USD / 100 万 x 3500 万 = 21.00 USD
合計 WAF 料金 = 60.00 USD/月

6.3 AWS NetworkFirewall

・IDSやWebフィルタ？
・これらのログはSIEMを使って分析するのがいいだろう。

7.具体的なセキュリティ機能❻イベントの通知や自動化処理

7.1 Amazon SNS

Amazon SNS（Amazon Simple Notification Service) は、アラームしきい値に達したときにメッセージを送信するなどに利用できます。
★それ以外にも、普通の連絡にも使える？
・まずはメールアドレスを登録する？

(1)設定画面

設定内容としては、以下です。
❶トピック作成
SNS のコンソールからトピックを作成し、名前やオプションを設定する。
❷サブスクリプション追加
トピックに対して受信エンドポイント（Email、SMS、HTTP/HTTPS、SQS、Lambda、モバイルプッシュなど）を設定する。
❸テスト通知
テストメッセージを発行して、設定が正しく動作するか確認する。
❹ポリシーと配信設定
必要に応じたアクセス制御や配信設定を追加する。

(2)連携可能なサービス

連携可能な主なAWSサービスは以下です。

サービス	説明
AWS CloudWatch	アラームやイベントの発生時にSNSへ通知を連携できます。システムのパフォーマンス監視や異常検知後の自動アクションのトリガーに利用されます。
AWS Config	リソースの設定変更やコンプライアンス評価の結果を監視し、設定逸脱や不正変更を検出した際にSNSへ通知することが可能
AWS Budgets	予算超過や設定したコスト閾値に達した場合に通知
Amazon GuardDuty	セキュリティ脅威の検知結果（Findings）が発生した際にSNSへ通知
AWS Health	AWSのサービス状態やメンテナンス情報、障害情報など、アカウントやサービスの健康状態に関する重要なイベントをSNS経由で通知

(3)通知方法

SNSを使った主な通知方法です。

通知方法	説明
Email	通常のメールやJSON形式のメールとして通知
SMS	ショートメッセージとして、モバイルデバイスに送信
HTTP / HTTPS エンドポイント	Webhook のように、指定したURLへPOSTリクエストで通知内容を送信
AWS Lambda	Lambda関数をトリガーして、通知を受けた際にカスタム処理や自動化ワークフローを実行

以下、サブスクリプションの設定画面です。さまざまな通知方法が選べます。

7.2 Amazon EventBridge

イベントバスとして各種AWSサービスや自社アプリケーションからのイベントを受信し、ルールに基づいて通知や自動化処理をトリガー。

7.3 Amazon Data Firehose

ログを他社（Splunkなど）に送信するには、Amazon Data Firehoseが使えそう。内容は要確認。
https://dev.classmethod.jp/articles/amazon-kinesis-data-firehose-for-beginner/

8.具体的なセキュリティ機能❼その他

8.1 Macie（メーシー）

・S3の中身をチェックする。S3のログを見て、チェックする（機密情報保護）。なので、S3を契約していないなら不要。
・クレジットカード情報やマイナンバーカードの番号など、機微な情報が含まれていないかを、機械学習とパターンマッチングで検出する機能。
・保護する機能ではなく、他のサービスと連携して保護する事はできるかもしれない。
・現在、原則は英語が識別子を検索したりするので、日本語対応は限定的。全角文字は使えず、マイナンバーのIDなどでのみ検索が可能

8.2 AWS Lambda

8.3 CloudWatch

Amazon CloudWatch は、AWS リソースやアプリケーションの運用状況を監視・管理するための統合監視サービスです。AWS Lambdaと連携して、攻撃を検知したらフィルタルールを書いて、通信をブロックすることもできる。

(1)具体的な役割

役割	内容
収集	CloudWatch Logs によるログ収集。CPU 使用率、メモリ使用量、ディスク I/O、ネットワークトラフィックなど、AWS リソースやカスタムアプリケーションのパフォーマンス指標（メトリクス）を収集
可視化	集約されたデータをダッシュボード（CloudWatch Dashboards）で可視化
通知・自動化	異常やしきい値を検知した際に、アラームやイベントをトリガーして通知や自動化処理を行う。具体的には、CloudWatch Alarms、EventBridge（CloudWatch Events）を活用した自動化、SNS 連携による通知

(2)VPC Flow Logsのログを見る

・VPC Flow Logsのログのところで設定したログを見てみる。

ロググループを選択すると、そこに生ログが見える。ファイルがわかれているので、少し見づらいかもしれない。

右側に、「すべてのログストリームを検索」とあるので、そこで全検索もできるであろう。
また、アクション　から「保持設定を編集」を押すと、どれだけログを保持するかを設定できる。期間を短くすれば、その分、ログの量が減る

(3)LinuxサーバのログをCloudWatchに転送

・手順は以下に解説あり。
https://zenn.dev/motisan/articles/20230122_cloudwatchlogs
・Linuxインスタンスにて、以下のコマンドで、Linuxのインスタンスにcloudwatchのエージェントをインストールする

yum install amazon-cloudwatch-agent -y

・設定によって、/var/log/secureなどのログを転送することができる。

8.4 データの暗号

(1)AWSの領域に保存したデータの暗号
・EBSは構築するときに暗号するかしないかが選択できる。
・メモリの暗号化もインスタンスを選ぶことで実現は可能になる。
(2)転送データの暗号（たとえば、インスタンス間のデータ通信）
　サービスごとに異なる
　・EC2はインスタンスによっても変わる
　・ダイレクトコネクトもデフォルトでは通信に暗号化はされない

8.5 Certificate Manager

ELBに証明書を入れることで、SSL通信が可能。ここでは、Certificate Managerを使ってHTTPSのサーバを構築してみる。

(1)設定の流れ

・AWSのインスタンスの起動（LinuxのWebサーバ）
・Certificate Managerで証明書を作成
・ALBの設定
・インスタンスのセキュリティGの変更
・Route53でDNSの設定（www2.53test.com)

※順番はどうなるのだろう？

(2)AWS Certificate Manager (ACM)で証明書の発行

a)AWS Certificate Manager (ACM)を開く
b)「証明書をリクエスト」から、「パブリック証明書をリクエスト」を選んで「次へ」

c)Route53で取得した独自ドメインによるFQDNを指定「www2.53test.com」

【参考】独自ドメインではなく、AWSのDNSだと失敗する 以下のようにAWSのDNS名で作ってみた。 ec2-18-135-xx.eu-west-2.compute.amazonaws.com 作成時、検証方法は、AWSのDNSの権限がないので、「Eメール検証」を選んだ。 それ以外はデフォルト 以下のようにエラーになった。

d)右上の「証明書を表示」を押す

e)Route53でレコードを作成　を押す

f)確認画面が出るが、「レコードの作成」を押す

g)「証明書を一覧」でステータスを確認する。※少し時間がかかる。私は翌日に確認してしまったため、どれくらい時間がかかったかは不明。

(3)ALBの設定：ターゲットグループ

ALBの設定で、以下を行う
a)ターゲットグループの作成
ロードバランシング>ターゲットグループから「ターゲットグループの作成」。インスタンスを選び、プロトコルはHTTP、ポートは80、VPCはインスタンスが存在する適切なものを選ぶ。
b)インスタンスを追加するが、「保留中として以下を含める」のボタンを押す

(4)ALBの設定：ロードバランサ―の作成

a)続いて、ロードバランサーから「ロードバランサ―の作成」、ALBを選ぶ
b)Application Load Balancer を作成の画面にて、
ロードバランサ名を入れ、インターネット向け（デフォルト）、ネットワークマッピングでは、
適切なVPCやサブネットを選ぶ。リスナーとして、HTTPSを追加し、先ほど作成したターゲットグループをHTTPとHTTPSの両方で選択する

c)セキュリティポリシーで、証明書をACM（デフォルト）として、先ほど作成した証明書を選ぶ。

d)「ロードバランサの作成」を押す
e)セキュリティグループを必要に応じて修正する。
デフォルトにあるルールは削除してしまっていいはず。新しくHTTPSを許可するルールを作る

(5)EC2インスタンスのセキュリティGの変更

この概念が難しいのであるが、HTTPに対して、LBのセキュリティGを許可する。HTTPSは不要。
今のHTTPのルールを上書きしようとしてもエラーが出る。新規で作らなければいけない。

9.その他

9.1 AWSでCSPM

CSPM専用の製品もあるが、AWSの機能がCSPMを実現しています。
AWS Security Hubや、AWS Config、Inspectorが該当すると言えるでしょうか。

9.2 RAM

RAM（Resource Access Manager）は、複数のアカウント間で AWS リソースを簡単かつ安全に共有
https://aws.amazon.com/jp/ram/

たとえば、Transit Gateway を使って複数の事業者（あるいは異なるアカウント）と接続する場合、Transit Gateway のリソース（たとえばアタッチメントやルートテーブル）の共有に RAM を利用することで、管理と運用が効率化されます。単一アカウントで完結している場合は、RAM を利用する必要はありません。

10.サポート

10.1 AWSのサポートプラン

AWSのサポートプランの一覧です。
https://aws.amazon.com/jp/premiumsupport/plans/
これとは別に無料のベーシックプランがあります。ただ、特にサポートは受けられないようで、アカウントなどに対するQ＆Aのようです。

プラン	ベーシック	デベロッパー	ビジネス	Enterprise On-Ramp	エンタープライズ
料金	無料	有料	有料	有料	有料
ターゲット	企業以外であろう	開発環境	企業の本番環境では 最低でも必須（と考える）
テクニカルアカウントマネージャー (TAM)	無	無	無	（専任ではないが） 有	有

※また、ログ解析などに関しても、ベーシックやデベロッパーでは、そもそも取得しているログが違うようです。

10.2 AWS Trusted Advisor

(1)概要

・SecurityHUBと同様に、AWSのベストプラクティスに沿っているかの評価をします。SecurityHUBはセキュリティのチェックですが、AWS Trusted Advisorは、以下のように、セキュリティ以外のリソースやコストやなどのチェックです。
・以下のカテゴリでベストプラクティスかどうかのチェックをしてくれます。

クラウドコストの最適化

パフォーマンス

耐障害性

セキュリティ

運用上の優秀性

サービスの制限

・無料プランでも実施できると思います。ビジネスプランなどになると、回数が増えるようです。

Trusted Advisor は、クラウドコストの最適化、パフォーマンス、耐障害性、セキュリティ、運用上の優秀性、サービスの制限などのカテゴリでベストプラクティスチェックを行い、お客様の AWS 環境を継続的に評価します。そして、ベストプラクティスからの逸脱を修正するためのアクションを推奨します。（https://aws.amazon.com/jp/premiumsupport/technology/trusted-advisor/)

・チェック結果はこんな感じです。

・コストの観点だと、未使用のリソースを削除したり、アイドル状態のリソースを停止するなどして、予想されるコスト削減も表示されます。

(2)セキュリティ

・セキュリティの項目もあるが、SecuryHubのAWSベストプラクティスのセキュリティ基準の内の一部、つまり簡易版です。
・チェックできる項目は、たとえば以下です。

・IAMユーザーに対してMFA（二要素認証）が設定されているか ・S3バケットが「誰でもアクセス可能」になっていないかを確認 ・0.0.0.0/0 でSSH (22番ポート) や RDP (3389番ポート) が許可されていないか確認。 ・特定のポートが過剰に開いていないか ・AWSアカウント全体でCloudTrailが設定されているか

11.商流

11.1 代理店とパートナー

(1)代理店

AWSのライセンスやサービスを販売する企業

分類	名称	通称	説明	事業者例
Tier1（一次代理店）	AWS Distributor	卸売代理店	他の再販業者（＝Tier 2）にAWSのライセンスやサービスを販売する企業。AWSから卸売権限を与えられている。	SB C&S、TD SYNNEX
Tier2（一次代理店）	AWS Solution Provider	販売パートナー	エンドユーザーに対してAWSを販売・請求・運用支援するパートナー。請求代行や割引提供が可能。再販権を持つ。	クラスメソッド、サーバーワークス、NTTデータなど

(2)パートナー

・APNパートナーは、AWSに認定されたすべてのパートナーの総称（技術支援・販売支援など）。
APNは、AWS Partner Network。Solution Provider と Distributor は、どちらも APNパートナーの一部である。一方、販売機能を持たない事業者もある。
・AWS Solution Providerにおいては、２次代理店なのでエンドユーザーに対してAWSを販売・請求が可能だが、多くは導入や運用を支援するパートナーとしての役割を持つことも多い。
・AWS Distributorは直接販売は出来ません。また、導入サポートなどのSI業務も原則はしません。
・APNパートナーに認定されていない事業者がAWSの支援などをしている場合ももちろんあります。違反ではなく、AWSに正式に認定されていない会社がやっているというだけです。

11.2 購入ルート

どちらのモデルでも、AWS パートナーがすべてのアカウントの請求を担当します。
セキュリティの観点からいうと、アカウント管理などで代理店を介さないECAMが望ましいと言えそうです。

購入先	説明	Account name and domain	商流
AWS（直販）	ECAM（End Customer Account Model ：イーキャム）モデル。AWS公式サイトまたは営業経由	below to End User	顧客 ──契約──▶ AWS（直接）　※代理店は介在しない。
Tier 2の代理店（Solution Provider）経由	SPAM（Solution Provider Account Model：スパム）モデル。代理店経由で購入	below to Solution Provider	顧客 ──契約──▶ Solution Provider（Tier 2代理店） ──仕入──▶ Distributor（Tier 1） ──▶ AWS

ECAMとSPAMについては以下も参照ください。
https://aws.amazon.com/jp/blogs/psa/aws-control-tower-best-practices-for-aws-solution-providers/