AWSの情報セキュリティは安全？主なリスク・対策とチェックリストを紹介

1. AWSの情報セキュリティは信頼できる？

AWSは、クラウド基盤の保護に関するさまざまな情報セキュリティ対策を備えた クラウドサービスです。高度なサイバー攻撃や内部セキュリティリスクにも対応できる、多層的な対策を備えており、安心して利用できる環境が整えられています。AWSの導入を検討する際は、こうした情報セキュリティ対策の内容を理解しておくことが重要です。

1-1. データ保護からコンプライアンス遵守まで幅広くリスクを管理

AWSは、データ保護やアクセス管理、脅威の検出、コンプライアンスへの対応など、幅広い情報セキュリティリスクを管理するための機能を提供しています。

データの暗号化やアクセス権限の制御、ログの記録・監視などを組み合わせることで、AWS上のデータやアプリケーション、各種リソースを保護できます。

また、国際的な情報セキュリティ規格や法令・業界基準への対応を支援する仕組みも用意されており、企業に求められる管理・監査体制を整えやすい点も特徴です。

これらの機能を活用することで、情報セキュリティ基盤をゼロから構築する場合と比べて、必要な対策を効率的に導入できます。

参照：クラウドセキュリティ | AWS

2. AWSの責任共有モデルとは

AWSの責任共有モデルとは、AWSと利用者がそれぞれ情報セキュリティ上の責任範囲を分担する考え方です。AWSはデータセンターや物理サーバーなどのクラウド基盤を保護し、利用者はAWS上に保存するデータやアカウント、アクセス権限、各サービスの設定などを管理します。

AWSと利用者の主な責任範囲は、以下のとおりです。

参照：責任共有モデル｜AWS

2-1. AWSが責任を負う範囲

AWSは、データセンターや物理サーバーなど、クラウド基盤の情報セキュリティに責任を負います。物理的な情報セキュリティ対策や設備の保守・更新などはAWSが担うため、利用者が対応する必要はありません。

オンプレミス環境では、自社でサーバーやネットワーク機器の保守・運用を行いますが、AWSではその負担を軽減できます。そのため、利用者はデータやアクセス権限など、自社が責任を負う情報セキュリティ対策に集中できます。

2-2. 利用者が責任を負う範囲

AWSの利用者は、AWS上に保存するデータやアクセス権限、各サービスの設定などを適切に管理する責任を負います。ただし、利用者が管理する範囲は、利用するAWSサービスによって異なります。

たとえば、Amazon EC2のようなIaaSでは、利用者はゲストOSやアプリケーションの更新に加え、データやアクセス権限の管理、セキュリティグループ（アクセスを許可する通信を制御する機能）による通信制御などを行う必要があります。

一方、Amazon DynamoDBのようなフルマネージドサービスでは、OSなどの管理はAWSが担いますが、保存するデータやアクセス権限、暗号化、バックアップなどの設定は利用者の責任です。

このように、利用するAWSサービスによって責任範囲は異なるため、自社が利用しているサービスごとに責任範囲を確認し、必要な情報セキュリティ対策を実施することが大切です。

利用者側の情報セキュリティ対策を見直したい方に向けて、NTT東日本では「クラウドセキュリティチェック for AWS」を提供しています。IAMやログ出力・監視、ネットワークなど、利用者側の責任範囲に関わる設定状況を診断できるサービスです。ご興味のある方は、ぜひサービス内容をご確認ください。

「クラウドセキュリティチェック for AWS」の詳細はこちら

関連コラム：AWSの責任共有モデルとは？事業者とユーザーの責任範囲や必要な情報セキュリティ対策を解説

3. AWSで発生しやすい主な情報セキュリティリスク

AWS環境では、利用者側の設定不備や運用ミスが情報セキュリティリスクにつながる場合があります。ここでは、特に注意したい以下のリスクについて詳しく解説します。

• 認証情報の管理不備によるアカウントの乗っ取り
• ストレージやネットワークの公開設定による情報漏えい
• ログ・監視設定の不足による異常検知の遅れ
• 脆弱性管理の不足によるシステム侵害

3-1. 認証情報の管理不備によるアカウントの乗っ取り

認証情報の管理に不備があると、攻撃者にAWSアカウントを乗っ取られ、不正に操作されるリスクがあります。

たとえば、次のような設定や運用が原因となります。

• rootユーザーの日常的な使用
• MFA（多要素認証）の未設定
• 業務上必要な範囲を超えた権限の付与
• アクセスキーが記載されたソースコードや共有ファイルの外部公開
• 不要なIAMユーザーの放置

アカウントが乗っ取られると、設定の改ざんやリソースの不正利用、データの窃取などが行われる可能性があります。これにより意図しない高額請求につながるおそれもあります。

3-2. ストレージやネットワークの公開設定による情報漏えい

ストレージやネットワークの公開範囲に不備があると、AWS上のデータやシステムへ外部から不正にアクセスされるリスクがあります。

たとえば、Amazon S3（オブジェクトストレージサービス）のパブリックアクセスを意図せず許可したり、セキュリティグループで接続元やポートを必要以上に広く設定したりすると、外部からのアクセスを許す原因になります。

こうした状況は、顧客情報や機密情報の漏えいにつながりかねません。また、保存中・通信中のデータが適切に暗号化されていなければ、第三者にデータを盗み見られるおそれもあります。

3-3. ログ・監視設定の不足による異常検知の遅れ

操作ログの記録や監視が不十分だと、不審な操作や通信を早期に発見できず、インシデントへの対応が遅れるリスクがあります。

たとえば、操作履歴を記録していなかったり、異常を検知・通知する仕組みを整備していなかったりすると、問題の発見が遅れやすくなります。また、ログを十分な期間保存していない場合や、監視対象・通知先が適切に設定されていない場合も、異常を見逃す原因となるため注意が必要です。

こうした状態では、不正ログインや権限変更、不審なリソースの作成などを早期に把握できず、被害が拡大する可能性があります。さらに、必要なログが残っていなければ、侵入経路や影響範囲の特定、再発防止策の検討も困難になります。

3-4. 脆弱性管理の不足によるシステム侵害

OSやアプリケーションなどの脆弱性を放置すると、攻撃者に悪用され、AWS上のシステムへ侵入されるリスクがあります。

たとえば、必要な更新やセキュリティパッチを適用しないまま運用を続けたり、サポートが終了したバージョンを使用し続けたりすると、脆弱性が悪用されかねません。

その結果、管理者権限の奪取やマルウェアへの感染、ほかのAWSリソースへの侵入などにつながる可能性があります。さらに、データの窃取・暗号化やシステム停止など、被害が拡大する可能性があります。

システム侵害を防ぐには、OSやアプリケーションの更新だけでなく、AWS環境全体の設定状況を定期的に見直すことも大切です。

NTT東日本の「クラウドセキュリティチェック for AWS」では、AWS CIS Foundations Benchmarkなどをもとに、設定不備や改善が必要な項目を診断できます。情報セキュリティリスクを把握し、改善につなげたい方は、サービスの特徴を資料でご覧ください。

「クラウドセキュリティチェック for AWS」の資料ダウンロードはこちらから

4. AWSで実施すべき5つの情報セキュリティ対策

AWSには、安全なクラウド環境の設計・運用に関するベストプラクティスをまとめた「AWS Well-Architected Framework」があります。本章ではAWS Well-Architected Framework内の「セキュリティの柱」を参考に、AWS環境で実施すべき情報セキュリティ対策を5つ紹介します。

• IAM・MFAを活用してアクセス権限を適切に管理する
• データを暗号化してバックアップを取得する
• ネットワークや公開範囲を必要最小限に設定する
• 操作ログを記録して異常を継続的に監視する
• 脆弱性管理とインシデント対応の手順を整備する

参照：AWS Well-Architected Framework

4-1. IAM・MFAを活用してアクセス権限を適切に管理する

アカウントの乗っ取りや権限の悪用、誤操作などによる影響を抑えるには、利用者やシステムへ必要な権限だけを付与し、認証を強化することが基本です。

IAM（AWS Identity and Access Management）は、AWSリソースへのアクセス権限を管理するサービスです。日常業務では、IAM Identity Centerなどを活用して利用者ごとのアクセスを管理し、用途に応じてIAMロールを使用します。IAMユーザーや長期的なアクセスキーを利用する場合は、必要な用途に限定し、定期的に棚卸し・見直しを行いましょう。

また、AWSアカウントのすべてのサービスやリソースへアクセスできるrootユーザーは、rootユーザーでしか実行できない作業に限って使用します。さらに、パスワードに加えて認証コードなどでも本人確認を行うMFAを設定し、認証情報が漏えいした場合の不正利用を防ぎましょう。

権限は業務に必要な範囲にとどめ、業務内容や担当者の変更に応じて定期的に見直すことが大切です。

関連コラム：多要素認証とは？二段階認証との違いやメリットデメリットまで解説

4-2. データを暗号化してバックアップを取得する

情報漏えいや通信の盗聴による被害を防ぐには、保存中と通信中のデータをそれぞれ暗号化して保護することが欠かせません。

Amazon S3などに保存するデータは、機密性や業務上の重要度に応じて暗号化します。また、外部との通信やAWSサービス間の通信には、通信内容を暗号化するTLSを使用し、通信経路上のデータも保護しましょう。

暗号化に使用する鍵は、AWS Key Management Service（AWS KMS：暗号化に使用する鍵を管理するサービス）などで適切に管理します。

さらに、重要なデータはバックアップを取得し、想定する時間内に復元できるかも定期的に確認しましょう。

関連コラム：AWS Key Management Service（KMS）とは？仕組みや使い方を解説

4-3. ネットワークや公開範囲を必要最小限に設定する

不正アクセスや意図しない情報公開を防ぐには、AWSリソースへ接続できる通信経路と公開範囲を必要最小限に制限することが重要です。

Amazon VPC（AWS上に仮想ネットワークを構築するサービス）では、セキュリティグループやネットワークACL（サブネット単位で通信を制御する機能）を利用できます。接続元・接続先・ポートなどを業務上必要な範囲に絞り、特にサーバー管理用のポートはインターネット上の不特定多数へ公開しないようにしましょう。

また、外部へ公開するWebアプリケーションには、AWS WAF（Webアプリケーションへの不正な通信を防ぐサービス）を組み合わせることも有効です。

各サービスの公開設定も確認し、公開が不要なリソースは非公開にします。新しいリソースの作成時だけでなく、システム構成や利用目的が変わった際にも公開範囲を見直しましょう。

関連コラム：AWS WAFとは？用途・メリットや料金体系から設定方法まで解説

4-4. 操作ログを記録して異常を継続的に監視する

操作ログの記録と継続的な監視により、不正アクセスや設定変更、不審な通信などを早期に発見でき、被害の拡大を防ぎやすくなります。インシデント発生後も、ログをもとに原因や影響範囲を調査することが可能です。

具体的には、AWS CloudTrail（AWS上の操作履歴を記録するサービス）などで利用者による操作やリソースの設定変更を記録し、Amazon GuardDuty（脅威を検知するサービス）などを活用して異常を検知・通知する仕組みを整えましょう。

また、異常を検知した際の通知先や対応担当者をあらかじめ決めておき、アラートを放置しない運用体制を整備しましょう。

関連コラム：Amazon GuardDutyによる脅威モニタリングとリアルタイム通知の実現

4-5. 脆弱性管理とインシデント対応の手順を整備する

脆弱性管理とインシデント対応では、問題が起きてから対応方法を考えるのではなく、確認頻度や更新フロー、担当者の役割を事前に定めておくことが有効です。

脆弱性管理では、次のような手順をあらかじめ定めておきましょう。

1. OSやミドルウェア、アプリケーションなど、脆弱性を確認する対象を整理する
2. システムの重要度に応じて、脆弱性情報を確認する頻度を決める
3. 脆弱性が見つかったら、システムへの影響を確認し、対応の優先順位を決める
4. 動作確認を行ったうえでセキュリティパッチを適用する

不正アクセスや情報漏えいなどのインシデントに備えて、次のような対応手順も定めておきましょう。

1. 担当者へ報告し、発生した事象を把握する
2. 影響を受けたシステムやデータの範囲を確認する
3. 不正な通信を遮断するなど、被害の拡大を防ぐ
4. システムを復旧し、原因の調査と再発防止策を実施する

あわせて、各手順の担当者や連絡先、対応方針を決める責任者を明確にします。緊急時に手順どおり対応できるよう、定期的に訓練を行い、必要に応じて内容を見直すことも大切です。

ここまで紹介したような複数の対策を講じていても、設定の抜け漏れや運用開始後の変更によって情報セキュリティリスクが生じる場合があります。

自社だけで設定状況を確認することが難しい場合は、第三者の視点による情報セキュリティ診断を活用する方法も有効です。NTT東日本では、AWS環境の設定状況を診断し、改善が必要な箇所をレポートで確認できる「クラウドセキュリティチェック for AWS」を提供しています。

AWS環境の情報セキュリティ対策を見直したい方は、以下の資料からサービスの特徴や診断内容をご確認ください。

「クラウドセキュリティチェック for AWS」の資料ダウンロードはこちらから

5. AWSの情報セキュリティ対策に役立つ主なサービス

AWSでは、アクセス管理や脅威検知、ログ管理など、目的に応じた情報セキュリティサービスが提供されています。代表的なサービスと、それぞれの役割は次のとおりです。

自社のシステム構成やリスクに応じて適切に組み合わせて活用しましょう。

6. 【チェックリスト】AWSの情報セキュリティ設定で確認すべき項目

AWSの情報セキュリティ設定は、導入時に確認して終わりではありません。利用者・リソースの増減やシステム構成の変更などに応じて定期的に見直す必要があります。

ここでは、自社で確認しやすい基本的な項目と、専門知識が必要な項目に分けて紹介します。

6-1. 基本的な確認項目

AWSマネジメントコンソールや社内の管理台帳などから確認しやすい項目は次のとおりです。

• rootユーザーにMFAを設定しているか
• rootユーザーを日常業務で使用していないか
• 退職者や異動者など、不要なIAMユーザーが残っていないか
• 長期間使用していないアクセスキーがないか
• Amazon S3が意図せず外部へ公開されていないか
• 重要なデータのバックアップを取得しているか
• バックアップから復元できることを確認しているか
• AWS CloudTrailで必要な操作履歴を記録しているか
• Amazon GuardDutyなどによる脅威検知を有効にしているか
• 異常を検知した際の通知先と対応担当者が決まっているか

基本的な項目は定期的に確認し、設定の変更や利用者の異動などがあった際にも見直しましょう。

6-2. 専門知識が必要な確認項目

次の項目は、設定の有無だけでは適切かどうかを判断しにくく、AWSサービスやシステム構成に関する知識が求められます。システム全体への影響も考慮しながら確認することが大切です。

• IAMポリシーが最小権限になっており、過剰な許可が含まれていないか
• セキュリティグループやネットワークACLで不要な通信を許可していないか
• インターネットから直接アクセスできるリソースが適切か
• 保存中・通信中のデータが、機密性に応じて暗号化されているか
• 暗号鍵や認証情報の保管・利用権限が適切か
• ログの対象、保存先、保存期間が調査・監査の要件を満たしているか
• アラートの検知条件、重要度、通知先が適切か
• OSやミドルウェア、アプリケーションの脆弱性が放置されていないか
• 複数のAWSアカウントやリージョンを横断して管理できているか
• インシデント対応手順が現在のシステム構成に合っているか

これらの項目は、設定の有無だけでなく、システム構成や運用状況を踏まえて適切かどうかを判断する必要があります。自社だけで判断するのが難しい場合は、第三者による診断を活用することも検討しましょう。

7. NTT東日本の「クラウドセキュリティチェック for AWS」で設定状況を診断

AWS環境を安全に運用し続けるには、設定状況を定期的に確認することが欠かせません。NTT東日本の「クラウドセキュリティチェック for AWS」は、運用中のAWS環境を第三者の視点から確認し、情報セキュリティ上のリスクと改善すべき設定を把握するためのサービスです。

「クラウドセキュリティチェック for AWS」では、AWS CIS Foundations BenchmarkやAWS基礎セキュリティのベストプラクティスに関する項目をもとに、主に次のような設定状況を確認します。

• ID・アクセス管理：rootユーザーやパスワードポリシーなどの設定
• ログ出力：AWS CloudTrailによる操作ログの記録設定
• 監視・通知：異常を検知した場合のアラーム設定
• ネットワーク：外部から不要なアクセスを許可していないか
• AWSリソース：Amazon EC2、Amazon S3、Amazon RDSなどの設定

診断結果はレポートとして提供され、リモート会議で改善策の説明も受けられるため、優先的に対応すべき設定や改善の方向性を把握できます。

NTT東日本以外の事業者が構築したAWS環境も診断の対象です。構築を委託していて現在の設定がわからない場合や、自社で構築した環境を第三者に確認してほしい場合にも利用できます。

AWS環境の現状を客観的に把握したい方や、診断の対象範囲・費用・進め方について相談したい方は、以下のフォームからNTT東日本へお問い合わせください。

クラウドに関するご相談・お問い合わせフォーム

8. AWSの情報セキュリティに関するよくある質問

AWSの情報セキュリティに関して、導入・運用時に生じやすい疑問へ回答します。

8-1. AWSの情報セキュリティ対策は万全ですか？

いいえ。AWSを利用するだけで情報セキュリティ対策が万全になるわけではありません。

責任共有モデルに基づき、AWSはクラウド基盤を保護しますが、AWS上のデータやアクセス権限、各サービスの設定などは利用者が管理する必要があります。そのため、自社でも継続的な情報セキュリティ対策が求められます。

8-2. AWSの情報セキュリティ設定はどのくらいの頻度で見直すべきですか？

一律の頻度は決められていませんが、四半期に1回程度を目安に主要な設定を見直すことが一般的です。ただし、扱う情報や法令・監査要件、システムの変更頻度に応じて、より短い間隔での確認が必要な場合もあります。

定期点検に加え、AWSサービスの追加やシステム構成の変更など、運用環境に変化があったタイミングでも見直しを行いましょう。また、担当者の変更やインシデントの発生、監査の前後も確認するタイミングです。

8-3. 自社だけでAWSの情報セキュリティ対策を行うことはできますか？

基本的な設定確認や定期的な見直しであれば、自社でも実施できます。たとえば、rootユーザーへのMFA設定や不要なIAMユーザーの有無などは、自社で確認しやすい項目です。

一方、IAMポリシーやネットワーク設定の妥当性の判断、ログ・アラートの設定などは、AWSやシステム構成に関する知識が求められます。複数のAWSアカウントやサービスを利用している場合は、環境全体を踏まえた確認も必要です。

自社だけで判断が難しい場合は、第三者による情報セキュリティ診断を活用する方法も有効です。NTT東日本の「クラウドセキュリティチェック for AWS」では、設定状況の診断結果をもとに改善策の説明を受けられるほか、有償で修正対応も提供します。

9. AWSの情報セキュリティ設定を定期的に見直そう

AWSは高い情報セキュリティ水準を備えていますが、責任共有モデルにより、利用者にもアクセス管理やネットワーク設定、ログ・監視などの情報セキュリティ対策が求められます。

また、導入時に安全な状態でも、利用者やリソースの増加、システム構成の変更などによって新たなリスクが生じる可能性があります。チェックリストを活用し、設定状況を定期的に見直しましょう。

AWS環境の全体像を把握できていない場合や、社内だけでは設定の妥当性を判断しにくい場合は、第三者の診断を活用することも選択肢です。NTT東日本が提供する「クラウドセキュリティチェック for AWS」の対象範囲や費用、進め方について詳しく知りたい方は、以下のフォームからお問い合わせください。

クラウドに関するご相談・お問い合わせフォーム

本コラムに記載されてる会社名、サービス名、商品名は、各社の商標または登録商標です。