- 目次
1. はじめに
近年、幅広い業種でパブリッククラウドサービスを活用する動きが高まっています。令和3年度版情報通信白書(※1)によれば、約7割の企業がクラウドサービスを利用しており、クラウドサービスの効果を実感したと回答した割合は約9割となっています。オンプレミス環境で動かしていた業務システムをクラウド環境へ移行することでコスト削減を達成したり、始めからクラウド環境でシステムを構築し運用するクラウドネイティブを実現することで、ビジネススピードを加速させようとしたりする企業が増えていると考えられます。そのため、今後もクラウドは成長戦略の一環としてますます重要視されることが予想されます。
しかし、思わぬ落とし穴として、パブリッククラウドに潜むセキュリティリスクが存在することに気を付けなければなりません。誰でも簡単に素早くクラウドサービスを利用できるメリットとは裏腹に、アクセス制御やデータの保護に関する設定が不適切に扱われることで、重大なセキュリティ事故につながる恐れもあります。本記事では、このようなパブリッククラウドに関するセキュリティの考え方や、インシデントの原因、さらにクラウドセキュリティの実装方法について説明します。
https://www.soumu.go.jp/johotsusintokei/whitepaper/ja/r03/pdf/index.html
2. パブリッククラウドにおけるセキュリティ脅威
パブリッククラウドで気にしなければならない脅威は数多くあります(図1)。これらの脅威がもたらす被害の中でも情報漏洩が最も重要です。具体的な原因は、「設定不備によるデータの公開」や「認証情報をソースコードに埋め込んでいる」などが挙げられます。つまり、適切な設定や制御をしなければ、重要なデータが外部にそのまま漏れてしまうということが言えます。
図1:パブリッククラウドで想定される脅威
表1は、パブリッククラウドで発生した情報漏洩の規模と原因をまとめたものです。情報セキュリティ白書2021(※2)によれば、クラウドにおける設定ミスによって情報漏洩が発生したものは5.1%であるものの、漏洩した情報の件数は全体の9割を占めており、ないがしろにすることはできません。
表1:パブリッククラウドにおいて発生した情報漏洩の規模と原因
(※被害規模は漏洩した可能性のあるデータ数を表示しています)
発生した年 | 被害規模 | 利用していたサービス形態 | 発生原因 |
---|---|---|---|
2021年 | 数千件 | SaaS | データが公開状態 |
2021年 | 数百件 | SaaS | データが公開状態 |
2020年 | 数千万件 | SaaS | データが公開状態 |
2020年 | 数百万件 | SaaS | データが公開状態 |
2020年 | 数千件 | SaaS | 不正アクセス |
2020年 | 数百万件 | IaaS/PaaS | データが公開状態 |
2020年 | 数十万件 | IaaS/PaaS | データが公開状態 |
2020年 | 数千件 | IaaS/PaaS | 不正アクセス |
2020年 | 数万件 | IaaS/PaaS | データが公開状態 |
2020年 | 数万件 | IaaS/PaaS | データが公開状態 |
2019年 | 数十万件 | IaaS/PaaS | データが公開状態 |
2019年 | 数億件 | IaaS/PaaS | 独自に設置したWAFの設定ミス |
2019年 | 数千万件 | IaaS/PaaS | データが公開状態 |
2019年 | 数億件 | IaaS/PaaS | データが公開状態 |
https://www.ipa.go.jp/security/publications/hakusyo/2021.html
3. クラウドセキュリティの実現方法
では、クラウドサービスではどのようにしてセキュリティリスクを低減すればよいのでしょうか。ここでは代表的なクラウドサービスであるAWS(Amazon Web Services)を取り上げて説明していきます。
3.1. クラウド事業者と利用者間のセキュリティ責任の所在
AWSのセキュリティに対する考え方として「AWS責任共有モデル」があります(図2)。これは、クラウド事業者と利用者のセキュリティ対策に関する責任範囲を表しており、明確に分離されています。AWSに限らず、AzureやGCPなど他のクラウドサービスも同様に責任共有モデルを定義しています。したがって、セキュリティ対策をすべてクラウド事業者に任せれば問題ないといった考えは誤りであり、利用者側で対応する責務があります。
AWS側の責任は、サービスを提供するために必要なデータセンターや物理的なハードウェア、仮想化を実現する仕組みといったインフラストラクチャを保護することです。具体的には、データセンター施設への侵入を防止する厳重な制御や、インフラストラクチャに関するパッチ管理や構成管理などがあります。
利用者側の責任は、サービスによって異なりますが、AWSが提供するインフラストラクチャ上にあるオペレーティングシステム、アプリケーション、データなどの管理をすることです。具体的には、AWSサービスに対するアクセス制御や、仮想ネットワーク内のネットワーク制御、データの暗号化、ログやイベントの監視などがあります。
したがって、クラウドサービスの利用者は、セキュリティリスクを顕在化させないために、洗練された設定を意識的に実施しなければなりません。
図2:AWS責任共有モデル
3.2. AWSにおける利用者側が実施すべきセキュリティの対策例
当社のクラウド環境におけるシステム開発の実績等を基に、AWSにおいてどのようにしてセキュリティを強化すればよいのかを説明します。図3はセキュリティ対策の具体例を表しています。
利用者の認証、AWSリソースへのアクセス制御をするには、AWS IAM(Identity and Access Management)を使います。多要素認証(MFA)を有効にすることで不正アクセスから守り、最小限のアクセス権限(IAMポリシー)を割り当てることで望ましくないアクションを防止します。
設定不備やセキュリティ事故をいち早く発見をするためにログやイベントの監視を行います。AWSリソースの情報や状態を記録するAmazon CloudWatchや、AWSアカウントの操作を記録するAWS CloudTrailなどを使います。また、構成変更を追跡するAWS Configを使用することで、データベースサービスやストレージサービス上のデータに誰でもアクセスできるようになっていないかを監視することができます。
ネットワーク制御をするには、AWS VPC(Virtual Private Network)を使います。外部公開しないサーバーは、インターネットに直接繋がっていないプライベートサブネットに置くことが望ましいです。制御には、サーバー単位にセキュリティグループ、サブネット単位にネットワークACL(Access Control List)を適用します。これらの設定が不適切な場合、攻撃者の侵入経路となる恐れがあります。また、VPC外に存在するサービスとはVPCエンドポイントを利用することでセキュアな設計を実現できます。
データを保護する上では、保管データと転送データに対して暗号化をする必要があります。各種サービスにおいて、暗号化を設定でき、本体データのみならず、スナップショット(バックアップファイル)も暗号化されていることが望ましいです。その際、AWS KMS(Key Management Service)を使うことでAWS側に保管データの暗号鍵管理を任せることができます。コンプライアンス要件が厳しい場合は、AWS Cloud HSM(Hardware Security Module)を適用します。また、転送データを暗号化する際のSSL/TLS証明書を管理するには、ACM(AWS Certificate Manager)を利用します。
図3:AWSサービスを活用したセキュリティ対策例
3.3. AWSのカバー範囲外のセキュリティ対策例
AWSサービスではカバーしきれない部分もあります。そのため、他製品の導入や、独自の仕組みの構築が必要です。重要なのは、責任共有モデルや各AWSサービスが何をカバーしてくれているのかを正しく理解し、漏れなく対策することです。AWSのカバー範囲外のセキュリティ対策の代表例を図4に示します。
図4:AWSサービスがカバーしていない範囲に対するセキュリティ対策例
4. 最後に
本記事では、パブリッククラウドに関するセキュリティ脅威や、対策方法を紹介しました。NTTデータでは、様々なクラウドサービスに対して、幅広いセキュリティ脅威を念頭においたセキュリティ要件定義、セキュリティ設計に尽力しており、お客様が抱える課題の解消を目指しています。