実際にあったインシデント事例をご紹介しながら、クラウドにおけるセキュリティの正しい実践方法をお伝えします！
企業におけるクラウドの利用が圧倒的に増えた昨今
クラウドとオンプレミスのセキュリティリスクの違いを正しく理解して
適切な対策を行うことは今や重要です。
当資料では、実際にあったインシデント事例をご紹介しながら
クラウドにおけるセキュリティの正しい知識を身につけ
実践するためのベストプラクティスをお伝えいたします。
【本編の目次】
1. インシデント事例とベストプラクティス
1-1. 脆弱なアカウント
1-2. インシデント対応に必要なログの欠如
1-3. S3バケットの公開設定
1-4. RDSの公開設定
1-5. 仮想マシン上のアクセスキー
1-6. 仮想マシン上の秘密鍵
2. クラウドセキュリティへの取り組み
2-1. クラウドとオンプレミスのセキュリティリスクの違い
2-2. クラウド利用に必要なセキュリティ対策
2-3. まとめ
このカタログについて
| ドキュメント名 | 【資料進呈中】クラウドのセキュリティで知っておくべきリスクと対策 |
|---|---|
| ドキュメント種別 | ホワイトペーパー |
| ファイルサイズ | 1.5Mb |
| 登録カテゴリ | |
| 取り扱い企業 | 株式会社SHIFT (この企業の取り扱いカタログ一覧) |
この企業の関連カタログ
このカタログの内容
Page1
クラウドのセキュリティで
知っておくべきリスクと対策について
Page2
はじめに：結論
結論
クラウドとオンプレミスのセキュリティリスクについて
相違点を正しく理解することが必要
相違点
責任分界点 変化スピード 可視化
1
Page3
はじめに：クラウドとオンプレミスとの相違点
例：ネットワーク構成の変更に必要な要素
データセンタ クラウド
入館申請 / 本人確認 / ラック鍵 パスワード / MFA / 権限・ポリシー
責任分界点：ベンダー 責任分界点：ユーザ
変化スピード：遅い 変化スピード：早い
可視化：見えている 可視化：見えていない
2
Page4
はじめに：ゴールとアジェンダ
ゴール
セキュリティリスクを正しく認識し、問題に対して適切に対策できる
アジェンダ
■ クラウドでのインシデント事例 ■ クラウドセキュリティへの取り組み
● インシデント事例の紹介 ● クラウドとオンプレミスのセキュリティリスクの違い
● インシデント状況と影響 ● クラウド利用に必要なセキュリティ対策
● ベストプラクティス ● まとめ
3
Page5
インシデント事例とベストプラクティス
Page6
インシデント事例とベストプラクティス
1.脆弱なアカウント
2.インシデント対応に必要なログの欠如
3. S3バケットの公開設定
4. RDSの公開設定
5.仮想マシン上のアクセスキー
6.仮想マシン上の秘密鍵
5
Page7
インシデント事例：脆弱なアカウント
事例 ： AWSフォーラム「my account was hacked」
● 大量のEC2インスタンスを暗号資産マイニングに利用された（被害：数十万～数百万円の請求）
● 補足①：Proof of Work(PoW)によりブロック生成を行う通貨では計算資源を使いブロック生成をし、その対価
としてマイニング報酬を得られる
● 補足②：近年のインシデントではハックされたシステム上での仮想通貨マイニングが散見される
AWS Cloud
EC2大量生成による
仮想通貨マイニング
不十分なユーザ管理（IAM）設定 IAM
・MFA（多要素認証）：無効 攻撃者が作成した大量のEC2
・パスワードポリシー：弱い
・権限管理：不要な権限も付与
アカウントハック
6
Page8
インシデント事例：脆弱なアカウント
■ 原因
● rootのパスワードが流出・推測され、アカウントが奪取された
● rootのアカウントがMFA等で保護されていなかった
■ 影響
● 既存サービスへの影響（過負荷）
● 多額の費用（暗号資産マイニング）
7
Page9
インシデント事例：脆弱なアカウント
ベストプラクティス
● 認証方法の管理（MFAの有効化、パスワードポリシーの設定）
● ユーザの管理（IAMユーザの権限最小化、rootアカウントの厳密な保管、非稼働ユーザの無効化）
● CloudTrail + CloudWatch （認証失敗、rootアカウント利用、MFA無しログイン）
AWS Cloud
IAM CloudTrail CloudWatch
8
Page10
インシデント事例：インシデント対応に必要なログの欠如
事例 ： インシデント対応後のログ調査
● EC2のインスタンスで過負荷を観測、マルウェアが検知された
● インシデントの調査を進めようとしたが、必要なログが残っていない
VPC AWS Cloud
Security group
ログの参照
ハック
RDS
EC2 ログの参照
デフォルトだと
スロークエリくらいしかない...
9
Page11
インシデント事例：インシデント対応に必要なログの欠如
■ 原因
● ログを保存する機能が有効化されていなかった
● ログがローテーションされていて最近の情報しか残っていない
■ 影響
● インシデントの影響範囲と情報漏洩の有無が分析不可能
● 再発防止策の策定が困難
10
Page12
インシデント事例：インシデント対応に必要なログの欠如
ベストプラクティス
● FlowLogsでVPC内の通信量を監視
● CloudWatch + CloudTrailで各種イベントを監視
● これらのログはS3に格納して長期保存する
VPC AWS Cloud
Security group ログを長期保存
S3 CloudWatch CloudTrail
EC2 RDS
FlowLogs
各種ロギング機能を有効化
11
Page13
インシデント事例：S3バケットの公開設定
事例 ： 日本企業海外法人の情報漏洩
● Webアプリケーション経由でS3バケットに格納していた数万件以上の個人情報（氏名、連絡先、パスワード
等）が漏洩した可能性がある
AWS Cloud
情報登録 格納 閲覧
EC2 S3
12
Page14
インシデント事例：S3バケットの公開設定
■ 原因
● S3バケットが公開設定になっていた
● 閲覧・書き込みが可能な状態になっていた
■ 影響
● 機微情報の漏洩・改ざん
● Webアプリケーションへの攻撃
13
Page15
インシデント事例：S3バケットの公開設定
ベストプラクティス
S3バケット全体のアクセス権限が適切か確認する
「アクセス権限>ブロックパブリックアクセス」で「パブリックアクセスをすべてブロック」をONにする
バケットの
「ブロックパブリックアクセス」で
AWS
Cloud ACL等による公開設定を無効化
EC2 S3
この設定が無い場合、バケットおよび格納オブジェクトのACLやポリシー設定によっては公開アクセスになる
14
Page16
インシデント事例：RDSの公開設定
事例 ： ランサムウェアによる被害
● RDSに保存されている全データが攻撃者によって暗号化された（被害：0.1BTCの身代金）
Security group
AWS ハック
Cloud
EC2 RDS
15
Page17
インシデント事例：RDSの公開設定
■ 原因
● RDSがグローバルネットワークからアクセス可能だった
● データベースのパスワードが流出・推測され、アカウントが奪取された
■ 影響
● RDSの全データが漏洩と身代金の要求
16
Page18
インシデント事例：RDSの公開設定
ベストプラクティス
セキュリティグループを分離 グローバルIPアドレスの解除
グローバルからアクセスできない 「パブリックアクセシビリティ」を
セキュリティグループを設定する 「なし」に設定する
セキュリティグループの設定ミス等があっても、 少
EC2 RDS なくともグローバルIPから直接アクセスされる恐れ
AWS
Cloud は無くなる。
SG SG
17
Page19
インシデント事例：仮想マシン上のアクセスキー
事例 ： アクセスキー漏洩による不正利用
● PublicなGitHubリポジトリに保存されたAWSのアクセスキーを悪用されて、大量のEC2インスタンスが構築された
AWS GitHub
Cloud
発行 保存
IAM
設定ファイル（WEB-INF）等
が強制ブラウジングできる場合 アクセスキー
にも注意が必要
APIを利用
不正利用
EC2 S3
18
Page20
インシデント事例：仮想マシン上のアクセスキー
■ 原因
● アクセスキーを生成し、ソースコードに直接書いていた
● PublicなGitHubリポジトリにソースコードをPushしていた
■ 影響
● 機密情報の流出
● 多額の費用（暗号資産マイニング）
19