AWSの主なセキュリティリスクとその対策

AWSなどのクラウドサービスを利用するメリットは明らかです。スケーラビリティと柔軟性に優れたアプリケーションを構築できるため、企業はSaaSのようなビジネスモデルへと移行しやすくなります。しかし、セキュリティを考慮せずにクラウドサービスを利用すれば、ビジネスの失敗につながりかねません。

Snykの調査によると、企業の10社中8社が過去1年間に深刻なクラウドセキュリティインシデントを経験しています。多くの組織にとって、深刻なインシデントが発生するかどうかではなく、いつ発生するかが問題です。差し迫るクラウドリスクを回避するには、早い段階から強固なAWSクラウドセキュリティ対策を確立することが最善の方法です。

AWSはデフォルトでどの程度安全なのか？

AWSは「デフォルトで安全」だと誤解しているユーザーは少なくありません。AWSはクラウドそのもののセキュリティを重視していますが、クラウド内のセキュリティに取り組むのはお客様です。つまりAWSユーザーである組織は、クラウドインスタンスとやり取りするすべてのもの（データ、コンテナ、社内ユーザーなど）のセキュリティ確保に責任を持つ必要があります。これはクラウドプロバイダーが「共有責任」と呼ぶ考え方であり、プロバイダーとお客様の双方がセキュリティのベストプラクティスに従うことを求めています。

AWSセキュリティにおける共有責任モデル

共有責任モデルのもとでは、AmazonがAWSの稼働を支える基盤となるソフトウェアとハードウェアを保護します。Amazonは自社側のセキュリティを可能な限り強化するために先を見越して取り組み、PCI-DSSやHIPAAなどのセキュリティおよびコンプライアンスのフレームワークに準拠しています。そのため、対処されていないセキュリティ問題の多くは、共有責任モデルにおけるお客様側に発生します。

AWSの主なセキュリティリスク10選とその対策

AWSユーザーがクラウド内のセキュリティで直面しやすい、よくあるリスクを10項目紹介します。

1. S3バケットの設定不備

非公開のコンテンツを誤って公開S3バケットに保存したり、非公開のS3バケットを誤って公開設定にしたりするのは簡単です。こうした単純なミスによって、誰もがS3バケット内の情報を閲覧できるようになり、その情報を使ってデータにアクセスされる可能性もあります。

2. IAM権限

Amazon Identity and Access Management（IAM）の設定を誤ると、後々深刻な影響が生じる可能性があります。不適切なアクセス権限が悪意あるユーザーの手に渡れば、許可されていない変更が加えられるおそれがあります。

3. AMIの誤公開

Amazon Machine Image（AMI）は、チームメンバーがAmazon Elastic Compute Cloud（EC2）インスタンスをすばやく起動できるテンプレートです。AMIを誤って公開してしまうことはAWSでよくある脆弱性の一つで、組織のクラウドシステムの内部構造が一般公開カタログに露出するおそれがあります。

4. クラウドセキュリティの可視性不足

組織のクラウド運用を全体的に把握できていないと、細かな問題を見落としがちです。これは、日々多くのチームメンバーがさまざまなAWSのコントロール、設定、インテグレーションを構成しているためです。つまり、保護するには、まず何が存在するのかを把握する必要があります。

5. 役割と責任範囲が不明確

AWSクラウドセキュリティに関する責任と責任範囲を明確にしなければ、セキュリティインシデントが発生しても誰も対応に乗り出さないかもしれません。これは大きなリスクです。一方、責任を適切な担当者に割り当てておけば、インシデントに迅速に対処しやすくなります。

6. クラウドに保存された機密データの保護不足

機密データをクラウドに保存するのは当然のことかもしれません。そのデータを先回りして保護する責任は、クラウドプロバイダーではなくお客様にあります。データ侵害の被害を受けないよう、保護対策を講じる必要があります。AWSは、暗号化やトランスポート層セキュリティ（TLS）の利用など、データを守るためのいくつかの予防策を推奨しています。

7. 設定ミスによる脆弱性

クラウドの設定ミスは、AWSでよくあるセキュリティリスクの原因となっています。クラウド環境の設定に不備があると、アプリケーション、コンテナ、インフラストラクチャ、その他のソフトウェアコンポーネントに適切なコントロールが設定されていない状態になります。

8. ソース管理や関数リポジトリに潜む脆弱性 

AWSのクラウドセキュリティは、クラウド自体の保護だけではありません。クラウド内に保存されたコードも安全でなければ、クラウド環境全体のセキュリティを確保できません。IaCの設定ミスや、自社開発コード、オープンソースコンポーネントに含まれるセキュリティ上の問題など、安全でないコードは、攻撃者が不正にシステムへアクセスするために悪用される可能性があります。また、AWS Serverless Application RepositoryやAWS CodeCommitに保存されているからといって、自動的に安全になるわけではありません。

9. Amazon Elastic Container Registry（ECR）のコンテナ脆弱性

コードとデータの安全性は、それらを格納するコンテナの安全性に左右されます。適切な設定（適切なID・アクセス管理、インフラセキュリティ、データ保護対策など）がなされていないAmazon ECRは、重大な脆弱性となる可能性があります。また、Amazon ECRで利用できる無料のオープンソーススキャナーは、NVDに登録された一部の既知の脆弱性をスキャンしますが、ベースイメージの選択後にしかスキャンしません。ベースイメージ自体もスキャンして更新しなければ、コンテナワークロードにセキュリティリスクが残るおそれがあります。

10. オープンソースの脆弱性

現在、ほとんどの企業が組織全体でオープンソースを利用しているため、オープンソースの脆弱性はクラウドインフラに影響を及ぼし、クラウドセキュリティ上の問題につながる可能性があります。オープンソースのリスクを把握するには、組織全体をエンドツーエンドで可視化し、ソフトウェア部品表（SBOM）などの最新のインベントリを使って、各コンポーネントの所在を理解することが重要です。直接依存・間接依存するオープンソースの依存関係を漏れなく把握するには、AWS上のアプリケーションスタック全体にわたり、開発から本番環境までセキュリティテストのゲートを適用する必要があります。

AWSクラウドのリスク管理を極める

AWSのセキュリティ問題を防ぐには？

AWSクラウドセキュリティは難しく感じるかもしれませんが、基本となるベストプラクティスはいくつかに集約できます。

• アプリケーション群全体にわたるクラウドリソースとセキュリティリスクのエンドツーエンドの可視化

• 強固なアクセス制御対策

• データセキュリティ対策

• 自社開発コードとオープンソースの両方を含む、安全なアプリケーションコード。

リスク管理フレームワークとポリシーの確立

リスク管理フレームワーク（RMF）は、データシステムに対するリスクの特定、評価、最小化を支援するために策定された、体系的な基準・ルールです。また、このフレームワークにより、チームは新たなセキュリティリスクを継続的に監視し、過去のリスクやプロセス、現在進行中の戦略について適切な記録を維持し、新たに発生する問題に迅速に対処できるようになります。

AWSクラウドにおけるリスク予防管理のメリット

AWSのリスク予防と管理は、次のような形で組織に役立ちます。

• セキュリティ。リスク管理は、不正アクセスやデータ侵害など、あらゆる種類のセキュリティリスクの特定と対処に役立ちます。

• 災害復旧。効果的な災害復旧計画を策定することで、ダウンタイムを大幅に短縮できます。

• コンプライアンス。AWSのクラウドサービスは、規制要件を満たすためのセキュリティコントロールとコンプライアンスフレームワークを提供します。

• リソースの活用。リスク予防により、組織は問題を先回りして追跡できるため、リソースをより効果的に活用できます。

• セキュリティ態勢。リスク予防ソリューションを適切に導入すれば、設定ミスを継続的に検出し、さらなるセキュリティ問題の発生を抑制できます。

SnykでAWSのセキュリティリスクに対処し、予防する

SnykはAWSなどのアプリケーションとクラウド環境を包括的に保護し、組織がこうしたセキュリティのベストプラクティスを実践できるよう支援します。SnykとAWSは、AWSのアプリケーションスタック全体にわたる多様なインテグレーションを共同で構築してきました。これにより、開発者やセキュリティ担当者は、AWS環境の設定ミスに加え、自社開発コード、オープンソースの依存関係、コンテナイメージ、TerraformやCloudFormationのIaC設定、さらには稼働中のKubernetes環境におけるアプリケーションレベルのセキュリティ問題を簡単に検出し、修正できます。

SnykとAWSのセキュリティツールとの連携について詳しく知り、クラウドセキュリティ態勢を強化する方法を、ぜひデモをリクエストしてご確認ください。