こんにちは。Flatt Securityの@toyojuniです。 "エンジニアの背中を預かる" をミッションに、日々プロダクト開発組織のセキュリティを意思決定から技術提供までサポートするべく奮闘しています。
さて、Flatt Securityはこの度3月2日(土)に池袋サンシャインシティにて開催されたJAWS DAYS 2024にPlatinum Supporterとして協賛し、ブースを出展させていただきました！
このイベントは日本全国に60以上の支部をもつAWSのユーザーグループ「JAWS-UG」が主催するもので、参加は有料でありながら1000人以上が参加者として登録している非常に大規模なものです。当日も大盛況でした！
日々AWSを用いてプロダクト開発・運用に向き合う皆様と直接お話しする機会は、我々にとって貴重なものでした。当日ブースにお越しいただいた皆様、ありがとうございました！
「AWSのセキュリティ課題を大調査！」企画
上述の通りイベント協賛の一環としてブースを出展させていただいたのですが、今回「AWSのセキュリティ課題を大調査」という企画を実施させていただきました。
JAWS DAYS 2024盛り上がっています！
— 株式会社Flatt Security (@flatt_security) 2024年3月2日
Flatt Securityブースで「AWSのセキュリティの困りごと」を回答いただくと必ずノベルティがもらえるおみくじに挑戦できます！
ぜひお越しください！ #jawsdays #jawsug pic.twitter.com/fkiD7nNuNF
アンケートボードは早くも大盛況！皆様ありがとうございます🔥 #jawsdays #jawsug pic.twitter.com/bK3WPZHBt0
— 株式会社Flatt Security (@flatt_security) 2024年3月2日
付箋に皆様の困り事を書いていただき、シェアしていただくという形式です。 こちらの企画も大盛況で、そこそこ大きいパネルを用意して行ったのですが、あっという間に埋まってしまいました！終盤は付箋の上に付箋を貼るような状態です。
最終的に、150のセキュリティ課題が集まりました。皆様本当にありがとうございました。
ここまでの数が集まると、統計データとしても有用そうです。実際ブースに立っていた我々としても、傾向のようなものが見えてきて非常に興味深かったです。
そこで、本ブログで集計結果をシェアさせていただきます。ぜひ、読者の皆様の抱えている課題と照らし合わせてみてください。
集計結果
それでは注目の集計結果ですが...以下の通りでした！ ざっくりの「課題のカテゴリ」ごとの付箋枚数をカウントしています。
| 項目 | 枚数(合計: 150) | 割合 |
|---|---|---|
| IAM | 32 | 21.3% |
| Security Hub | 18 | 12.0% |
| AWS自体の難易度 | 12 | 8.0% |
| ログ | 12 | 8.0% |
| 脆弱性パッチ対応 | 10 | 6.7% |
| マルチアカウント | 8 | 5.3% |
| セキュリティ意識・リテラシー | 6 | 4.0% |
| WAF | 5 | 3.3% |
| GuradDuty | 5 | 3.3% |
| S3 | 4 | 2.7% |
| コンテナ | 4 | 2.7% |
| セキュリティグループ | 4 | 2.7% |
| シークレットキー | 3 | 2.0% |
| その他 | 27 | 18.0% |
IAMの存在感が圧倒的ですね。その次にSecurity Hub、AWS自体の難易度...と続きます。 なお、同じカテゴリでも2枚しかないものは「その他」にまとめました。
「その他」以外を円グラフにまとめると、以下の通りです。
課題の具体例
それぞれのカテゴリごとにはどのような課題が挙げられていたのでしょうか。いくつか抜粋して紹介します。
※主旨は損なわないようにしつつ、表現は適宜変更しています。
IAM
- 最小権限の設計が難しい
- 管理・棚卸しが大変
- サーバーレスフレームワークのIAMが難しい
- IAM Roleを使いまわしている
Security Hub
- アラートが多すぎて対処できていない
- 自社にフィットしない / 必要ない検査項目がある
- コンソールが見づらい / 使いづらい
- 検知したはいいが、対応できる人がいない
AWS自体の難易度
※厳密には「AWSのセキュリティ関連サービスの難易度が高い」という課題です。
- セキュリティサービスが多くて覚えきれない
- セキュリティサービスをどれから使えばいいかわからない
- 知識がある人がいないとセキュリティサービスを扱えない
ログ
- RDSの監査ログを手軽に取りたい
- CloudTrailの監査ログを活用できていない
- Firehoseを使わずに簡単にログを見たい
脆弱性パッチ対応
- EC2のパッチ適用がほったらかし
- 脆弱性スキャンの実施
- 脆弱性ハンドリングを嫌がる人が多い
マルチアカウント
- SCPの設定ができていない
- マルチアカウントの管理・統制が大変
セキュリティ意識・リテラシー
- セキュリティに詳しい人がいない
- AWSもセキュリティもわかる人がいない
WAF
- ルールが多すぎてどれを当てていいかわからない
- ルールがわかりづらい
GuardDuty
- 導入しっぱなしで分析できていない
- 通知が多すぎる
S3
- ポリシー設定が難しい
- パブリック周りの設定がわかりづらい
コンテナ
- ECSのセキュリティがわからない
- Fargateの監視をしたい
セキュリティグループ
- 許可を消し忘れる
シークレットキー
- KMSでの暗号化の徹底が大変
その他
- 社内のポリシーに沿った形でセキュリティを実装していくのが大変
- root userのMFAが個人に紐づく
- セキュリティ系サービスを導入するときのコストがわかりづらい
- 施策のスピードとのトレードオフ
ここからは、アンケート結果の分析を弊社のセキュリティエンジニアにバトンタッチしようと思います。
Flatt Securityの分析
どうも、セキュリティエンジニアの@Azaraです。JAWS DAYSでアンケートにお答えいただいたみなさま、大変ありがとうございました。自分自身も共感できる課題も多く、ずっと頷きながら、アンケートを読ませていただきました。
本節では、アンケートの結果をもとに、AWSのセキュリティに関する課題について気になった点について、分析と所感を述べたいと思います。
IAM系
まず、単体の項目としてはIAMの管理や設計に関する課題が多く見受けられました。その中では以下のように3つの課題が挙げられていました。
- IAMポリシーの設計と最小権限の実施
- IAM Role・ポリシー・ユーザーの管理
- ポリシーにおける条件の複雑さ
IAMポリシーの設計と最小権限の実施
IAMに関する回答の中で3分の1以上の方が挙げていた課題が「IAMポリシーの設計と最小権限」でした。Well-Architected Frameworkやベストプラクティスでも強調されているように、多くの方が意識を持っている課題と言えるでしょう。その中でも、設計の段階でのつまづきや、徹底の困難さが挙げられていました。
IAM Role・ポリシー・ユーザーの管理
IAMポリシーの設計や最小権限に関する課題の次に多く挙げられていたのが、IAM Role・ポリシー・ユーザーの管理に関する課題でした。特に、IAMポリシーに関しては、最小権限を実施する上で重要な、権限の棚卸しや、ポリシーの適用範囲の把握、乱立するポリシーの整理などが挙げられていました。
また、IAM Roleに関しては、最小権限の原則に則り、ユースケースごとにRoleを分割を行うことで、運用が複雑化しているという課題も挙げられており、最小権限を実施した上での運用の課題も多く見受けられました。
ポリシーにおける条件の複雑さ
最後に挙げられていた課題として、ポリシーにおける条件の複雑さが挙げられていました。こちらも、最小権限を実施する上で重要なポイントであり、特に、ConditionやResourceの指定において、複雑な条件を設定することで、ポリシーの可読性や運用の複雑さが増すという課題が挙げられていました。
以上のように、IAMに関する課題については、設計段階から運用まで、幅広い課題が挙げられており、特に、最小権限を実施する上での課題が多く見受けられました。
所感
これらIAMに関する課題についての所感として、AWSアカウント内の関心事が大きくなればなるほど、IAMポリシーの最小権限の実装というのは、難易度が増すと考えられます。例えば、複数のプロダクトが同一アカウント内に同居する状況や、開発や本番などの環境が混在する場合、制御すべきリソースやタグなどの条件が複雑化し、それに伴い、存在するアクターやコンテキストが増えれば増えるほど、IAMポリシーにそれらを反映させる必要がありIAMポリシーの設計や運用が複雑化することが考えています。
最善で対策を取るのであれば、マルチアカウント化(用途によるアカウントの分割)やサービスの分割(モジュラーモノリス等)を行い、アカウントやリソースの関心事を小さくすること、そして必要になった際にアカウントやVPCなどを連携するといったことが良いとは考えます。一方現実はそう全てが最善で動くわけではないので、腰を据えて、サービスのユースケースの整理や役職や部署、職務、機能単位での最小権限を整理するなどし、付与することが重要だと考えます。
セキュリティサービス系
次に、アンケート結果を俯瞰してみると「SecurityHub」や「GuardDuty」、「AWS(のセキュリティサービス)自体の難易度」などのAWSの提供するセキュリティサービスに関する課題が、複数カテゴリにわたって多く見受けられました。
これらのサービスは、それぞれが異なる観点からセキュリティの状態を監視するためのサービスであり、それぞれのサービスが提供する情報を活用することで、セキュリティの状態を把握することができ、AWSエコシステム内でのセキュリティの状態を把握や、ベースラインを整える上では非常に有用なものです。
一方で、これらのサービスは導入すれば全てが解決するという「銀の弾丸」ではありません。
アンケートでも、SecurityHubの導入時点での検査結果の多さや、UIへの不慣れさ、またそれぞれのサービスが提供する情報をどのように活用すべきかなど、多く課題の具体例が挙げられており導入以後にどのように活用すべきかという点について、課題が多く見受けられました。
また、通知やアラートに関しては、課題の常態化により、適切に対応できていないという課題や、一つ一つ地道に指摘事項を解決していくのが、最善の策ではあるが、開発組織においては、セキュリティの運用に関する課題を解決するためのリソースを割くことが難しいという課題も見受けられました。
所感
所感としては、上記のようなサービスを導入を行うことで、埋没していたセキュリティ課題が多く表面化した状態が、多くの企業において見受けられるのではないかと考えられます。最善なのは一つ一つ課題を解決していくことではありますが、それには、複数の障害があると考えます。
そこで一つの提案ですが、1週間に10~30分、定期的にセキュリティ課題に目を通して、その課題に対してどのように対処すべきかを考える時間を設けてみてはいかがでしょうか。その際に対応しなくても大丈夫です。その対応すべき課題をリストアップすることで大きく困難な塊に見えていたコンソールが、対処をすべき簡潔なリストに変わるかもしれません。
Shisho Cloudの紹介
最後に、弊社の「Shisho Cloud(シショウ クラウド)」のご紹介です。
Shisho Cloudは皆様のチームでクラウドセキュリティ診断を内製で実践するためのサービスです。 わかりやすいUIや日本語レポートにより、今回のアンケートで皆様がSecurity Hub等の運用で抱えていたような課題を解決できるほか、AWS・Google Cloudのマルチクラウドの一元管理も実現できます。
先ほど、定期的にセキュリティ課題を俯瞰して対処を考える時間を設けると良いという話もしましたが、導入企業のヤプリ様ではShisho Cloudを用いてまさにそのような体制を作っていただきました。
セキュリティワークでは、Shisho Cloudを画面投影しながら、重要度の高い順に検出結果を確認しています。検出結果に対するレポートを読み合わせた上で、SRE・セキュリティエンジニアそれぞれの立場から意見を出し合い、対応方針やトリアージについて議論しています。定期的に行うことで、検出結果を放置せず、地道にリスクを減らしていく体制が出来上がりつつあると感じています。
ご興味のある方は、ぜひ公式サイトよりお問い合わせください。
終わりに
共感できる要素は多分にありつつも、改めてこのようにデータで見てみると新鮮な印象を受けるアンケート結果だったのではないでしょうか。
複雑化の一途を辿るソフトウェア開発の現場で、よりエンジニアの皆様をサポートできるよう、Flatt Securityは今回の結果も踏まえてサービス開発・改善を続けてまいります。 最新情報を見逃さないよう、公式Xのフォローをぜひお願いします！
では、ここまでお読みいただきありがとうございました。
