- 1.AWSのセキュリティについて
- 2.具体的なセキュリティ機能❶ユーザおよびアクセス権
- 3.具体的なセキュリティ機能❷監視およびログの保存
- 4.具体的なセキュリティ機能❸セキュリティ診断、セキュリティ監査
- 5.具体的なセキュリティ機能❹攻撃の防御
- 6.具体的なセキュリティ機能❹その他
- 7.サポート
1.AWSのセキュリティについて
1.1 はじめに
予防的統制と発見的統制
| 統制 | 内容 | サービス例 |
|---|---|---|
| 予防的統制 | ルール違反をさせないために適用する。 | 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%と少ない。
1.2 無料で利用できるもの
・IAM
・AWS ShieldによるDDoS対策（一定程度の簡易な防御）。有償版もあり
・ネットワーク系の通信の防御
－NetworkACLやSecurityGroupによる防御
・AWS WAF
1.3 デフォルトで対応されているもの
❶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.4 最低限実施したい対策
(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)アクセスキー
AWSにログインするには、ユーザを作成して管理コンソールからログインする方法以外に、アクセスキーを使う方法があります。アクセスキーとシークレットアクセスキーがあればログインできてしまうため、管理は慎重にしなければいけません。
アクセスキーの管理は、右上のユーザの名前からプルダウンで「セキュリティ認証情報」の「アクセスキー」でアクセスキーの状態を把握し、不要なアクセスキーは削除しましょう。
1.5 参考：農水省の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のインスタンスをセキュリティを保って管理ができる。
(2)用語の整理
| 用語 | 説明 | 関係性 |
|---|---|---|
| IAM（アイアム）ユーザ | AWSの操作をするユーザ。上限5000個 | |
| IAMグループ | IAMユーザをグループ化する。上限100 | |
| アクション | AWSの各サービスやリソースに対する各種の操作（追加、変更、削除など） | 一つのポリシーは、複数のアクションから成り立ってる |
| ポリシー | アクションをグループ化したもの。デフォルトはAWSがいくつも用意してある。個別に作成も可能 | 一つのユーザやロールには複数のポリシーを割り当てることができる |
| ロール | たとえば、S3などのストレージは、ユーザが接続する場合もあれば、他のシステムやAWSのサービスが利用する場合もあります。ユーザを定義するのがIAMユーザで、該当する資源へのアクセス権を設定するのがロールです。なので、あるシステムからのログをS3のバケットに出力しようとすると、S3にユーザを割り当ててもいいが（できるかは不明）、ユーザを割り当てずにロールを割り当てることが一般的です。 ロールを作成すると、以下のように対応付ける資源を選定できます。  |
一つのロールに複数のポリシーを割り当てることができる |
(3)割り当ての例
1)ユーザにログイン権限とEC2の権限の割り当て
この後に解説する。IAMユーザを作成し、そこにポリシー（アクションをグループ化したもの）を割り当てる。
2)ユーザにS3のバケットを割りあて
ユーザとIAMグループを作り、IAMグループに対して、ポリシー（アクションをグループ化したもの）を割り当てる？（要確認）
2)他のサービスにS3バケットへのアクセス権を割りあて
たとえば、外部のシステムからのログをS3に保管する
ポリシーを作成し、S3にロールを割りあてる？その際にロールにポリシーを対比づける？？
(4)多要素認証
・特にルートユーザに関しては、認証を強化する必要があります。以下、ログインには、ルートユーザとIAMユーザの2種類がある。
AWSが用意している多要素認証は、以下があります。
・パスキーまたはセキュリティキー
・認証アプリケーション
・ハードウェア TOTP トークン
↑は、ルートユーザでログインし、右上の自分のログイン名をクリックして「セキュリティ認証情報」>「多要素認証 (MFA) 」から表示できます。
(5)設定の流れ
・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 デバイスの割り当て
(6)送信元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を用いてAWSアカウントを作成しています。
https://drive.google.com/file/d/1P3AXxZo0BIw4DSsDc40Rp4Yqa3AmuHRd/view
OUを作成してルールを作れるので、たとえばアメリカのリージョンではインスタンスを作成できないなどの統一ルールを作れる（と思います★）
3.具体的なセキュリティ機能❷監視およびログの保存
3.1 GuardDuty（ガードデューティ）
(1)概要
・フルマネージド型の「脅威検出サービス」です。
| 機械学習を活用し、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を受け取り、怪しいと思うのを通知？（不正通信） これらは明示的にONにしなくてもいい。GuardDutyをONにすると、裏で自動で取得する。
たとえば、portScan 悪意のあるIPや、不正なポートへの、ブルートフォース攻撃
ただ、検知だけでブロックはできないので、CloudWatchなどを連携する必要がある。
・GuardDutyを有効化するためには、他のCloudTrailなどの設定は不要です。AWSのGuardDutyが勝手にやってくれます。
(2)WAFとの違いは？
WAFはインスタンスより外側で検知する。また、レイヤがレイヤ７のアプリケーションレベルが主。GuardDutyは、インスタンスに届いたパケットなどAWSの内部のトラフィックを分析する。
(3)設定
・リージョンを選択した上で、GuarDutyを開く
・「今すぐ始める」を押して、「GuarDutyを有効にする」を押す
・「GuardDutyを有効にする」と有効になります。設定の画面から、「GuardDuty を一時停止」や「GuardDuty を無効にする」ことも可能です。
(4)追加の保護プラン
いくつかあり、年々アップデートされている。
(5)GuardDuty Runtime Monitoring
https://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/runtime-monitoring.html
完全リアルタイムではなくても、リアルタイムに近い検知ができる。
ファイルレスも検知できるというが、どこまでできるかは要調査。
(6)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、他のサービスからの操作のログ。
・10万イベントあたり2ドルなどの費用がかかる。
・外部の攻撃も内部による設定ミスも検知する。（★本当？）
・CloudTrailは管理イベントに関しては、デフォルトで有効で、90日間のログを取っている。また、データの操作やインサイト（7日間のベースラインでの異常なアクティビティ）、ネットワークアクティビティに関しては、設定が必要★
・90日以上のログを保存するには、S3を活用する。Cloud Watch Logsと連携可能。
・リージョンサービス
(2)設定
・CloudTrail > イベント履歴 にて、履歴を見ることができる。
(3)取得できるログ
ログは非常に多岐にわたる。たとえば、「instance」で検索しても、以下のように、インスタンスを起動（StartInstance）、停止（StopInstance）などを含め、たくさんある。
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.4 Nortification service
何かあったら、メールで通知するサービス。まずはメールアドレスを登録する
3.5 Amazon Data Firehose
ログを他社（Splunkなど）に送信するには、Amazon Data Firehoseが使えそう
https://dev.classmethod.jp/articles/amazon-kinesis-data-firehose-for-beginner/
3.6 SIEM on Amazon OpenSearch Service（OSS）
SIEMを使ったログ分析
https://www.tis.jp/special/platform_knowledge/cloud22/
4.具体的なセキュリティ機能❸セキュリティ診断、セキュリティ監査
4.1 Amazon Inspector
ソフトウェア脆弱性が無いか、意図していない情報が公開されていないかなどの脆弱性診断を自動でやってくれるサービス
ただ、内容はそれほど本格的では無いように感じた。基本はCVEかな。あとは、PWの文字数制限をかけているとか、・・・
https://www.wafcharm.com/blog/amazon-inspector-for-beginners/
・以下の3つがスキャン対象
1)Amazon EC2インスタンス：パッケージの脆弱性、ネットワーク到達可能性（ポートスキャンではなく、セキュリティグループなどの設定を見て判断している）
2)Amazon ECRコンテナイメージ：
3)AWS Lambda関数：パッケージの脆弱性、コードの脆弱性
・インスタンスへのエージェントが必要
・エージェントレスのスキャンも可能。その場合、EBSのスナップショットがスキャンされる。もちろん、リアルタイム性で劣る。
・Inspectorスコアは、CVSSスコアを基に算出される。
・CVE番号を含む脆弱性を把握しているので、脆弱性スキャンはやりやすいですよね。ただし、万能ではない（★どんな場合？RPMじゃなくコンパイルしたものはダメ？）
・追加の脆弱性管理も検討する必要がありそう。
・例えば、CTFdのインスタンスがあって、その問題にeicarファイル
をUPloadしたとする。しばらくすると、Guard Dutyで検知する。
4.2 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)結果の確認
とりあえず結果の画面になるが、数分で結果が表示されるだろう（※以下はインスタンスが無いので、特に何も表示されていないが・・・）
・「準拠」がルールに適用していて、「非準拠」は赤で表示される。
・左のメニューのルールを見ると、ルールが確認できる。
4.3 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にすることで、コストを確認することができる。
5.具体的なセキュリティ機能❹攻撃の防御
5.1 AWS Shield
DDoS攻撃の対処。デフォルトで有効化されているが、AWS専属エンジニアの解析が必要な場合は有償のAWS Shield Advancedを利用する。
・無料は、Amazon CloudFrontとAmazon Route53への検知がメインだが、インスタンスのDoSも多少は有効
・無料はL3,L4レベルまで。Advancedを使うとL7までできそう。ただ、月額3000ドルくらいするから非常に高額。
・Advancedになると、しきい値のチューニングなどもできる。また、DDoS攻撃によってコスト増があっても、Advanceであれば調整してもらえる。
5.2 AWS WAF
・無料版と有料版がある
・SQL Database、 IPレピュテーションなどのルールセットがあり、それを適用する。
・AWSマネージドルールグループには以下がある
| ルールグループ | 概要 |
|---|---|
| ベースライン | たとえば、SQLインジェクションの基本的な攻撃を防ぐのはここに含まれている |
| ユースケース固有 | |
| IP 評価ルールグループ |
5.3 AWS NetworkFirewall
・IDSやWebフィルタ？
・これらのログはSIEMを使って分析するのがいいだろう。
6.具体的なセキュリティ機能❹その他
6.1 Macie（メーシー）
・S3の中身をチェックする。S3のログを見て、チェックする（機密情報保護）。なので、S3を契約していないなら不要。
・クレジットカード情報やマイナンバーカードの番号など、機微な情報が含まれていないかを、機械学習とパターンマッチングで検出する機能。
・保護する機能ではなく、他のサービスと連携して保護する事はできるかもしれない。
・現在、原則は英語が識別子を検索したりするので、日本語対応は限定的。全角文字は使えず、マイナンバーのIDなどでのみ検索が可能
6.2 AWS Lambda
6.3 CloudWatch
AWS Lambdaと連携して、攻撃を検知したらフィルタルールを書いて、通信をブロックすることもできる。
(1)VPC Flow Logsのログを見る
・VPC Flow Logsのログのところで設定したログを見てみる。
ロググループを選択すると、そこに生ログが見える。ファイルがわかれているので、少し見づらいかもしれない。
右側に、「すべてのログストリームを検索」とあるので、そこで全検索もできるであろう。
また、アクション から「保持設定を編集」を押すと、どれだけログを保持するかを設定できる。期間を短くすれば、その分、ログの量が減る
(2)LinuxサーバのログをCloudWatchに転送
・手順は以下に解説あり。
https://zenn.dev/motisan/articles/20230122_cloudwatchlogs
・Linuxインスタンスにて、以下のコマンドで、Linuxのインスタンスにcloudwatchのエージェントをインストールする
yum install amazon-cloudwatch-agent -y
・設定によって、/var/log/secureなどのログを転送することができる。
6.4 データの暗号
(1)AWSの領域に保存したデータの暗号
・EBSは構築するときに暗号するかしないかが選択できる。
・メモリの暗号化もインスタンスを選ぶことで実現は可能になる。
(2)転送データの暗号（たとえば、インスタンス間のデータ通信）
サービスごとに異なる
・EC2はインスタンスによっても変わる
・ダイレクトコネクトもデフォルトでは通信に暗号化はされない
6.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のルールを上書きしようとしてもエラーが出る。新規で作らなければいけない。
7.サポート
7.1 AWSのサポートプラン
AWSのサポートプランの一覧です。
https://aws.amazon.com/jp/premiumsupport/plans/
これとは別に無料のベーシックプランがあります。ただ、特にサポートは受けられないようで、アカウントなどに対するQ＆Aのようです。
・ベーシック
・デベロッパー
・ビジネス：企業で導入するときはここが最低になるだろう。
・Enterprise On-Ramp
・エンタープライズ
7.2 AWS Trusted Advisor
・SecurityHUBと同様に、AWSのベストプラクティスに沿っているかの評価をします。SecurityHUBはセキュリティのチェックですが、AWS Trusted Advisorは、以下のように、セキュリティ以外のリソースやコストやなどのチェックです。
・以下のカテゴリでベストプラクティスかどうかのチェックをしてくれます。
| クラウドコストの最適化 |
| パフォーマンス |
| 耐障害性 |
| セキュリティ |
| 運用上の優秀性 |
| サービスの制限 |
・無料プランでも実施できると思います。ビジネスプランなどになると、回数が増えるようです。
| Trusted Advisor は、クラウドコストの最適化、パフォーマンス、耐障害性、セキュリティ、運用上の優秀性、サービスの制限などのカテゴリでベストプラクティスチェックを行い、お客様の AWS 環境を継続的に評価します。そして、ベストプラクティスからの逸脱を修正するためのアクションを推奨します。（https://aws.amazon.com/jp/premiumsupport/technology/trusted-advisor/) |
・チェック結果はこんな感じです。
・コストの観点だと、未使用のリソースを削除したり、アイドル状態のリソースを停止するなどして、予想されるコスト削減も表示されます。
・セキュリティの項目もあるが、SecuryHubのAWSベストプラクティスのセキュリティ基準の内の一部、つまり簡易版です。
