aws-recipe-user こんにちは！HEROです 。
今回もリスクとコンプライアンス、クラウドセキュリティアライアンスの内容についてご紹介します！
▼これまでの記事はこちらをご参照下さい。
AWSセキュリティ編～リスクとコンプライアンス編①～
AWSセキュリティ編～リスクとコンプライアンス編②～
AWSセキュリティ編～リスクとコンプライアンス編③～
AWSセキュリティ編～リスクとコンプライアンス編④～
AWSセキュリティ編～リスクとコンプライアンス編⑤～
これだけのボリュームがあるとセキュリティがどれだけ重要なのか、重視されているかがよくわかりますね。
今回は前回の続きから情報のセキュリティについてみていきましょう。
◯不適切なアクセスがあった場合は？
ISO 27001 規格の附属書 A、 ドメイン 11.2について調べてみました。
・A.11.2 利用者アクセスの管理
情報システムへのアクセスを許可された利用者へ限定することを目的とし、情報システム、サービスへのアクセスをコントロールするため、情報システムへ利用ユーザーの登録、削除のための手順を確立して、特権管理ユーザーの割り当ても制限、管理する必要があります。
パスワード割り当ての手順を確立、管理して利用ユーザーのアクセス権限も定期的に見直す必要があります。
この『定期的に見直す』の箇所が90日のようですね。
PCなどの定期的なパスワード変更に近いイメージのようです。
◯情報セキュリティに関連する団体に参加しているか？
COBIT（control objectives for information and related technology）フレームワークとは、情報システムコントロール協会 (ISACA)とITガバナンス協会 (ITGI)が1992年に作成を開始した情報技術 (IT) 管理についてのベストプラクティス集のことです。
1996年に初版がリリースされた、比較的新しいフレームワークみたいですね。
◯情報セキュリティに関するインシデントに関して監視、分析を行っているか？
ISO 27001 規格の附属書 A、 13.2 について調べてみました。
・A.11.2 利用者アクセスの管理
情報セキュリティインシデントの速やかな報告体制を確立を目的とし、情報セキュリティインシデントの対応手順と体制をを策定する必要があります。
インシデントを事例としてとらえ対応策と再発防止策を策定する必要があります。
情報セキュリティインシデントの証拠（アクセスログやエビデンス）は収集、保管する必要があります。
再発防止ももちろんですが障害がほぼおきないAWSはさすが！としか言いようがありませんね。
いかがでしたでしょうか？
次回もお楽しみに！
