アクセンチュア、ウォールストリートジャーナル…最近多発するAWSのセキュリテイインシデントに何か対策はあるのだろうか
まず、「データが漏洩したらユーザーの責任」です。
さらにAWS利用開始時に同意を要求される約款には「約款を任意のタイミングで変更できる」と書いてあります。
上の2つはAWSのセキュリティを考える意味でスタートラインに立つために合わせておきたい基本的な認識です。
先日、Amazon S3 のバケットポリシーやアクセスコントロールリスト(ACL)に対して“All Users” や “All Authenticated AWS Users” に設定されているユーザに対し注意喚起のメールが送信されましたがこれは特例と考えて良いでしょう。
責任分担モデルについて公式では
While AWS manages security of the cloud, security in the cloud is the responsibility of the customer.
と書いていますが、要するに設定通り動くように管理はするが、”動いた結果の責任はOS,仮想ファイアウォール、データ、ネットワーク、アプリケーション問わず全てユーザが責任をおってくださいね。”と書いてあります。
これは相当にエスパーな技術者でも、一般的な企業でも簡単に負えるものではないと思います。そもそも何かしらの「ここがチェックできていれば大丈夫ですよ」と行った基準がなければ不安になるのが普通ではないでしょうか。
オンプレミスでやってきたから、ある程度自信があるという方は次のステップを考えてみましょう。
サービス実態とサービスの可用性は一致できる体制か
AWSには現在約90のサービスがありそれらを組み合わせることで柔軟なサービスを展開しています。裏を返せば時々刻々と変化するサービスの実態を等身大に把握し瞬時に対応しきる体制を維持することは並大抵なことではありません。
技術的なウェイトの高いオートスケーリングなどがサービスにより担保される分、「サービスの運用」が重視されます。
「AWS セキュリティ監査のガイドライン」が提供されていますがあくまでガイドラインの位置付けで具体的な基準は示されていません。次の「AWSセキュリティ監査の評価基準」を確認すべきです。
ベンチマークに従ったAWSセキュリティ設定の具体的な確認方法|CIS AWS Foundation Benchmark
CIS(Center for Internet Security)は、セキュリティの促進を目的とした米国の非営利団体です。このCISが発表しているには”Level1: 設定が必須のもの”,”Level2: 環境により設定が必要なもの”とおおまか分ける基準ではありますが、相当数の項目があるためスコアリングとしてある程度の実用性があると考えられます。
ダウンロードできるPDFには具体的な確認方法や設定手順が記載されています。
次の章におおまかなお題目の翻訳を載せておきます。本体は148ページの英文PDFなので少し気合を入れて読む必要がありそうです。
概要の参考URL
https://aws.amazon.com/jp/blogs/security/tag/cis-aws-foundations-benchmark/
具体的な内容参考URL
https://www.cisecurity.org/cis-benchmarks/
1. 認証関連(IAM)の確認と概要
IAMに関しては以下のチェック項目があります。
- rootアカウントが利用されていないこと(Level1,Scored)
- コンソールログイン用のパスワードが設定されたIAMユーザにMFAが有効化されていること(Level1,Scored)
- 90日以上利用されていない認証情報は無効化されていること(Level1,Scored)
- アクセスキーが90日以内にローテーションされていること(Level1,Scored)
- パスワードポリシーが設定されていること
- 1文字以上の大文字(Level1,Scored)
- 1文字以上の小文字(Level1,Scored)
- 1文字以上の記号(Level1,Scored)
- 1文字以上の数字(Level1,Scored)
- 14文字以上のパスワード(Level2,Scored)
- パスワードの再利用禁止(Level1,Scored)
- 90日以内のパスワード有効期限(Level1,Scored)
- rootアカウントのアクセスキーが設定されていないこと(Level1,Scored)
rootアカウントはテストの申請と金銭関係以外は原則利用せず、IAMユーザを利用すること、パスワード認証はやめて公開鍵認証方式(PKI)に切り替えることの2つは最低限やりましょう。
2.ログ出力関連(Logging)の確認と概要
ログ出力に関しては以下のチェック項目があります。
- 全RegionでCloudTrailが有効であること(Level1,Scored)
- CloudTrailログファイルの検証が有効化されていること(Level2,Scored)
- CloudTrailログの格納バケットが公開設定となっていないこと(Level1,Scored)
- CloudTrailログがCloudWatch Logsに配信設定されていること(Level1,Scored)
- 全RegionでAWS Configが有効であること(Level1,Scored)
- CloudTrailログの格納バケットがログ有効化されていること(Level1,Scored)
- CloudTrailログがSSE-KMSで暗号化設定されていること(Level2,Scored)
- KMSマスタキーがローテーション設定されていること(Level2,Scored)
- rootアカウントがハードウェアMFAにより保護されていること(Level2,Scored)
- 秘密の質問が設定されていること(Level1,NotScored)
- IAMポリシーがグループまたはロールにのみ適用されていること(Level1,Scored)
ログは何かトラブルがあった時の強い味方です。ログ自体を保護する観点が大切です。
3. 監視関連(Monitoring)の確認と概要
監視に関しては以下のチェック項目があります。
- 許可されていないAPIコールに対して、アラーム通知設定されていること(Level1,Scored)
- MFAなしでのAWSマネージメントコンソールログインに対して、アラーム通知設定されていること(Level1,Scored)
- rootアカウントの利用に対して、アラーム通知設定されていること(Level1,Scored)
- IAMポリシーの変更に対して、アラーム通知設定されていること(Level1,Scored)
- CloudTrail設定の変更に対して、アラーム通知設定されていること(Level1,Scored)
- AWSマネージメントコンソールのログイン失敗に対して、アラーム通知設定されていること(Level2,Scored)
- KMSマスターキーの無効化またはスケジュール削除に対して、アラーム通知設定されていること(Level2,Scored)
- S3バケットポリシー変更に対して、アラーム通知設定されていること(Level1,Scored)
- AWS Config設定の変更に対して、アラーム通知設定されていること(Level2,Scored)
- Security Group設定の変更に対して、アラーム通知設定されていること(Level2,Scored)
- Network ACL設定の変更に対して、アラーム通知設定されていること(Level2,Scored)
- Internet Gateway設定の変更に対して、アラーム通知設定されていること(Level1,Scored)
- Route Tabley設定の変更に対して、アラーム通知設定されていること(Level1,Scored)
4. ネットワーク関連(Networking)の確認と概要
ネットワークに関しては以下のチェック項目があります。
- Security Groupにて、0.0.0.0/0からport 22(SSH)への接続が許可されていないこと(Level1,NotScored)
- Security Groupにて、0.0.0.0/0からport 3389(RDP)への接続が許可されていないこと(Level1,NotScored)
- 利用可能な全てのRegionにおいて、VPC Flow Logsが有効化されていること(Level2,NotScored)
- Default Security Groupが全ての通信を許可していないこと(Level2,NotScored)
- VPC設定(新規作成、削除やVPC Peering, Classi Link等)の変更に対して、アラーム通知設定されていること(Level1,Scored)
- セキュリティ担当者の連絡先が設定されていること(Level1,Scored)
- SNS TopicのSubscriberに適切な連絡先が設定されていること(Level1,NotScored)
受け入れる送信元アドレスを「0.0.0.0/0」に設定されていると、どのIPアドレスからでも接続可能です。まさかそんな設定がとおもいますが、スマホのテスト用に設定したポートなどテスト期間中とはいえ開けていたりしませんか。
以上です。参考になれば幸いです。