この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは、臼田です。
みなさん、AWSのセキュリティベストプラクティス実践できてますか？(挨拶
今回は、Security-JAWS運営メンバーが調査を実施し、レポートとしてまとめた「Security-JAWS Insights AWSセキュリティのベストプラクティスに関する利用実態調査レポート」の内容を解説するとともに、僕自身の提言をまとめます。
これを読んで頂くと、「周りのみんなはAWSのベストプラクティスどれくらいできているの？」「自分たちは十分にベストプラクティスに沿えているのか？」といった疑問の回答が得られます。
なお、このレポートは[拡散希望]です。以下のツイートをじゃんじゃん拡散していただけると嬉しいです。
[拡散希望]Security-JAWS Insightのレポートはこちらです！https://t.co/NZmgbg6ZOp#secjaws28 #secjaws #jawsug #サイバーセキュリティは全員参加
— Security-JAWS✴︎0310AWSSaRMForum (@security_jaws) February 28, 2023
レポート概要
調査の背景
まずは調査の背景から。
みなさんは、AWSのベストプラクティスをどれくらい実践できていますか？
簡単なものもあれば難しいものもあり、「理屈ではわかっているんだけど、実践できていないな〜」とか「漠然としていて具体的にどこまでやればいいんだろう？」とか、疑問に思うことが多いのではないでしょうか？
というわけで、実際みんなどれくらいやっているの？というのをSecurity-JAWSからみなさんにアンケートを取って調査することにしました。
アンケート結果
アンケートは第25回のSecurity-JAWSで募集を開始し、2022/5/30 ~ 2022/7/31の期間でGoogle Formを使った収集を行いました。主にSNSを使ったアンケートフォームの拡散を行い、日本国内で、自社の業務において何かしらの形でAWSの利用に関与している人で、業種・職種・役職・会社規模・雇用形態問わず回答していただきました。期間中に162件の有効回答を頂きました。ご協力いただいたみなさんありがとうございました。
アンケートの規模として少なすぎるということはありませんが、統計を取るレベルには程遠いため、様々な偏りとバイアスがあることを事前にご認識ください。
いくつかの観点で回答者属性の内訳のグラフを出します。
会社規模
回答者の所属している会社規模はぼちぼちバラけています。
- 〜10人: 10件
- 11〜30人: 4件
- 31〜100人: 16件
- 101〜300人: 31件
- 301〜500人: 15件
- 501〜1000人: 21件
- 1001〜5000人: 28件
- 5001人〜: 37件
今回は後で出てくる分析の表で、ざっくり下記の分類としても扱っています。
- 小規模組織
- 〜10人
- 11〜30人
- 中規模組織
- 31〜100人
- 101〜300人
- 301〜500人
- 大規模組織
- 501〜1000人
- 1001〜5000人
- 5001人〜
AWS業務経験年数
回答者の個人的なAWS業務の経験年数も割とうまく分かれました。
- 〜1年: 20件
- 1〜3年: 51件
- 3〜5年: 39件
- 5〜10年: 48件
- 10年〜: 4件
10年選手という強者は少なめでした。しかしこれはなかなかの猛者ですね。
ロール
回答者のロールを複数回答可で取得しました。特に多かった上位3種は以下です。
- インフラエンジニア
- セキュリティエンジニア
- アプリケーションエンジニア
偏りがあるため、これは特に回答のバイアスになっているので、気にしていただければと思います。
ピックアップ解説
レポート結果についていくつかピックアップして、内容の解説や考察・提言を入れていきます。本当は全てについて話したいところですが、いろいろ大変なので下記4つのテーマを取りあげます。
- どのAWSセキュリティのベストプラクティスを活用しているか
- アクセス制御をちゃんとできているか
- 発見的統制をどうやって実現しているか
- 重要なデータの破棄について考えているか
どのAWSセキュリティのベストプラクティスを活用しているか
まずは「AWS環境を設計・構成する上で参照しているAWS公式ドキュメントを教えてください(P.13)」というアンケート結果です。これはAWSのセキュリティに関するベストプラクティスのドキュメントがたくさんあるので、どれを使っているか調査する目的で、複数回答可の設問を用意しました。候補に上げてものは下記6項目です。(一部重複がありましたのでレポートでは割愛しています)
- AWS の基本的なセキュリティのベストプラクティスコントロール
- AWS セキュリティのベストプラクティス
- AWS Well-Architected
- IAM でのセキュリティのベストプラクティス
- AWS クラウド導入フレームワーク (AWS CAF)
- AWS でバックアップを保護するためのセキュリティベストプラクティス Top 10
これは企業の状態より個人に依存する回答であることから、AWSの経験年数で集計を行いました。以下のような結果です。
パット見て目につくところは、10年以上の経験年数がある方はAWS Well-Architectedの参照率が100%です！これはすごい！１０年以上の経験者が4人と母数が少ないためでもありますが、全体的に経験年数が長いと各ベストプラクティスの参照率は高くなる傾向があるため、母数が増えてもAWS Well-Architectedの利用率が100%に近いことは期待できそうです。
経験年数が関係なくともAWS Well-Architectedの参照率が一番高いです。AWSセキュリティに限らないベストプラクティスであることも一因であると思いますし、つまり知名度も一番高いからとも言えるでしょう。
前半4種のドキュメントはどれも参照率が半数程度はあるため、これらはメジャーなドキュメントであると言えます。一方で、AWS セキュリティのベストプラクティスは、すでにアーカイブされたドキュメントであるにも関わらず参照率が高いところは気になるところです。個人的には、セキュリティの原理原則は比較的普遍的であるため、アーカイブされても参考になる箇所が多いという性質と、明確な後続ドキュメントが存在していないといったところが大きな要因ではないかと考えています。後続ドキュメントが待ち望まれますね。
ここで、「ドキュメントがいろいろあってどこから手を付けたらいいかわからないよ〜」という方にアドバイスです。
これだけ様々なドキュメントがあるのは、セキュリティというものが広範囲に渡り適用される領域であるからです。適材適所でこれらを使い分けていくと、いい付き合い方ができるでしょう。
例えば、AWS Well-Architectedはベストプラクティスへの取り組み方や考え方がまとまっていて、AWSの利用フェーズに関わらず適用できます。利用開始時の設計段階から、構築中、運用中も活用できます。一方で概念的なところが多く、一度ですべてのことを理解することが難しいでしょう。ドキュメント量も多いです。そのため私はよく、「Well-Architectedはスルメのようなもの」と表現しています。噛めば噛むほど味が出てくるスルメのように、繰り返し活用していくといいでしょう。
AWS の基本的なセキュリティのベストプラクティスコントロールはAWS Security Hubで検出する危険なAWSの設定をベースとした、具体的なパラメータレベルまで定義されたベストプラクティスの実践方法です。各種設定の危険度に応じた優先度が振られ、具体的な回避方法と理由が明記されており、AWS Security Hubの運用と組み合わせて是正を行っていくことで、AWSのセキュリティベストプラクティスを実践できます。すぐに危険なものをチェックして是正できることから、すでにAWSを利用している環境で即時効果を発揮できるメリットがありますが、個別のベストプラクティスの解決でありAWS環境全体にまたがってベストプラクティスを適用できるわけではないことは注意する必要があります。
私のレコメンドとしては、この2つのドキュメントを活用しつつ、利用している各AWSサービスのセキュリティページ(例えばAmazon S3 のセキュリティ - Amazon Simple Storage Service)も参照していくといいと思います。
アクセス制御をちゃんとできているか
ここでは下記2つのアンケート結果を拾います。
- 技術者や運用担当者がAWS環境を操作するために、どのような方法でアクセスしますか？(P.46)
- EC2インスタンスへのログインはどのように行っていますか？(P.50)
それぞれ、AWS環境へのアクセス制御と、EC2へのアクセス制御です。アクセス制御はITセキュリティの中でも基本的な機能であり、しかしおろそかにされがちな箇所です。見ていきましょう。
まずはAWS環境へのアクセス制御から。下記の様々な方式を複数回答可で取得し、会社規模で集計しました。
- IAMユーザー(ID+パスワード)
- IAMユーザー(ID+パスワード+MFA)
- IAMユーザー(ID+パスワード+MFA+スイッチロール)
- IAMロール(SSO)
- AWS CLI(永続的なクレデンシャル)
- AWS CLI(一時的なクレデンシャル)
- CI/CDツールでAWS環境を操作している(永続的なクレデンシャル)
- CI/CDツールでAWS環境を操作している(一時的なクレデンシャル)
最低限のセキュリティとしては「IAMユーザー(ID+パスワード+MFA)」ですが、これでも全体としては半数も利用されておりもう少し頑張ってほしいところです。「IAMユーザー(ID+パスワード+MFA+スイッチロール)」という、いわゆるJumpアカウント方式による、マルチアカウント戦略でIAMユーザー管理アカウントと利用アカウントを分け、アタックサーフェイスを減らしたりログイン情報の管理数を減らす方法は「301〜500人」の規模で特に採用率が高くいい感じですね。
ベストプラクティスに反する「IAMユーザー(ID+パスワード)」のみが「5001人〜」規模で他の会社規模とダブルスコアの20%近く残っていたり、SSO利用率も大規模組織が低いことから、このあたりも頑張ってほしいところです。
続いてEC2へのアクセス制御です。下記4項目を複数回答可で確認しています。
- SSH・RDP
- AWS Systems Manager Session Manager（ポートフォワード含む）
- EC2 Instance Connect
- EC2インスタンスへのログインは行わない
「SSH・RDP」の利用率が一番高く、ベストプラクティスに反しますがこれが実情であると言えます。しかしながら「AWS Systems Manager Session Manager（ポートフォワード含む）」の利用率も高く、非常に普及していると言えるレベルでしょう。比較的アジリティとセキュリティを確保しやすい中規模組織でこれらが普及していることは予想通りですが、大規模組織でもSession Managerが普及しているのは予想外でした。大規模組織でこれらが利用できていない会社のみなさんは、このデータを積極的に活用していただきたいです。
一方でより進んだセキュリティ対策である「EC2インスタンスへのログインは行わない」という手法は全然浸透していませんね。実現が難しいため仕方がありませんが、挑戦する価値のある方法ですので、みなさんにはこれを目指していただきたいです。具体的にはCI/CDパイプラインを構築して、直接本番環境へアクセスしないという手法があげられます。データと人を分離するというベストプラクティスですね。
発見的統制をどうやって実現しているか
『「発見的統制」として使っているAWSサービスなどを教えてください(P.60)』というアンケートの結果です。「発見的統制」の言葉や意味がどれくらい浸透しているかは少し心配なところですが、下記のようにサービス名別で質問したため少しは回答しやすかったのではないでしょうか。
- GuardDuty
- Config Rules
- CloudTrailログ
- CloudTrail Insight
- CloudWatch
- AWS Security Hub
- AWS Trusted Adviser
- AWS Cost Anomaly Detection
- IAM Access Analyzer
- サードパーティツール（ツール名をその他に記載）
私が嬉しかったのはAmazon GuardDutyの利用率が301~500人規模で86%もの高いスコアを出していたことです。Amazon GuardDuty普及担当(自称)としてはめちゃくちゃ嬉しいです。全体としても60%程度と比較的高い数値です。しかし、私は全AWSアカウントでAmazon GuardDutyが有効化されることを目標としているため、これからも普及活動に努めます。とりあえず有効化していないそこのあなた、すぐに有効化ボタンをポチッと押してください。
このあたりのAWSの純正サービスを利用した発見的統制はだいたい、中規模組織や大規模組織の中でも下の方の501〜1000人あたりまでが山なりに高くなる傾向がありました。大規模な組織はクラウドネイティブな取り組みに迅速な対応が難しいことが考えられますね。小規模組織は知識・経験やコストの観点で取り組めていない可能性があります。しかしAmazon GuardDutyやAWS Security Hubなどは少ないコストで沢山のセキュリティ運用を肩代わりしてくれますから、私としては小規模な環境や企業規模からも利用してほしいですね。
あとは利用率の低かったIAM Access Analyzerも無料の機能ですから、全員利用してほしいです。
重要なデータの破棄について考えているか
最後に「AWS環境の重要度が高いデータを廃棄するときに行っていることを教えてください(P.102)」です。AWS上に保管したデータの破棄方法について下記項目を複数回答可で問いました。
- 各リソースを暗号化せずに、ただ削除する
- 各リソースを暗号化したKMSキーや暗号鍵の無効化・削除
- 削除ログの保存
業務上関わっていない方も多かったですが、実施している方の中では「各リソースを暗号化せずに、ただ削除する」が一番高いという危険な実態が見れました。会社の規模で変わらない、ということも特に危ないです。大規模組織でもこの統制ができていません。
よく私が聞くこの手の問題としては次のような認識から来るものです。「AWSのセキュリティは非常に強固だから、自身でデータの暗号化までやらなくてもいい」「データの破棄はAWSのプロセスがしっかりしているから、AWSに任せればいい」。
これらの考えは全て間違いです。
AWSは責任共有モデルに基づき、AWSの中のセキュリティについては責任を持ちます。例えば利用しなくなったストレージデバイスの物理的な破棄は下記のような記載があります。
AWSにおけるメディアの廃棄
AWS データセンターは、セキュリティを念頭に置いて設計されており、統制により具体的なセキュリティが実現されています。ユーザーデータの保存に使用されるメディアストレージデバイスは AWS によって「クリティカル」と分類され、そのライフサイクルを通じて非常に重要な要素として適切に取り扱われます。AWS では、デバイスの設置、修理、および破棄 (最終的に不要になった場合) の方法について厳格な基準が設けられています。ストレージデバイスが製品寿命に達した場合、NIST 800-88 に詳細が説明されている方法を使用してメディアを廃棄します。ユーザーデータを保存したメディアは、安全に停止するまで AWS の統制から除外されることはありません。AWSで扱われるメディアはワイプ処理もしくは消磁処理され、AWSのセキュアゾーンを離れる前に物理的に破壊されます。AWS の第三者レポートに文書化されているように、AWS データセンターに対する第三者の検証によって、AWS がセキュリティ認証取得に必要となるルールを確立するためのセキュリティ対策を適切に実装していることが保証されます。お客様はこうした第三者のレポートをAWS Artifactから入手することが可能です。
しかし、データの責任はどうなっているでしょうか？責任共有モデルの表では常に一番上にこれが位置し、すべてユーザーの責任になっています。
つまり先程のようなことを顧客に説明することは大きな間違いです。AWSはデータの責任は利用者にあるとしていますから、顧客に対して「預かった重要なデータをどのように破棄しているか」という説明責任は利用者にあります。
当然実現方法としてはAWS KMSの利用などを行う必要があり、すべての処理をユーザーの責任で行う必要はありません。この辺の考え方は、説明責任(Accountability)と実行責任(Responsibility)という言葉でわかりやすく下記の本で解説してあります。まだ読んでいない方は全員読んでください(強い推奨)。
例えばあなたが、様々な顧客に対しマルチテナントで、顧客の重要データを収集するSaaSのサービスを運営していると想定してください。エンドユーザーがこのサービスを解約する時に「適切に重要データの破棄をしたことを説明してください」と言われた時にどうしますか？１つの手法としては、顧客単位でKMSの鍵を使い分け、顧客解約時にCryptographic Erase(CE:暗号化消去)を実施する方法があげられます。このようなデータのライフサイクルにおける破棄プロセスまで、設計段階から考慮できていますか？最初から考慮しないと実現が難しいですから、セキュリティ・バイ・デザインの大切さが伝わるでしょう。
まとめ
アンケートを集計してみて、様々なAWSのセキュリティを日々見ている立場としての率直な感想は「概ね順当な結果だった」です。
実現しやすい対策はだいたい実施されていて、実現しにくいものはとことん低いという実情でした。
みなさんはこの結果を見てどのように感じましたか？
これからAWSのセキュリティに取り組んでいく方や、日々やろうと思ってもできていないな〜と感じていた方は、この結果を使って周りの方を説得し、「まずは平均まではあげていきましょう！」と上申したりして速度感を持って対応してください。
平均付近で安心したというみなさん、それは間違いです。ベストプラクティスの利用実態の平均ではありますが、ベストプラクティスの平均ではありません。満たすべき基準はもっと高いです。この結果の平均にいるということは「最低限のAWSセキュリティしか実現できていない」と考えるべきでしょう。つまり全然足りません。実現が簡単でないセキュリティ対策であるからこそ、意味と価値がありますから、もっと上を目指して頑張りましょう。
この結果を参考にしつつ、みなさんが高い目標をもってAWSのセキュリティ対策を実現できることを、私は応援します。
7
