🚀
Cloud Security Day 2024 に参加なう
今日もイベントレポートです。
何でこのイベントに参加しようと思ったのかというと。。。。ご招待いただいたからｗ
僕自身なんで招待いただいたか全然分かってないのですが、かなりしっかりした招待状だったのでどんなものか気になって来てみました！
実際入ってみたら本当に講演を生で聴ける状態だったのでびっくりしていますｗ
目の前に講演者がいる、なかなかいい機会だなぁ
ハッシュタグ: #CloudSecurityDay2024
Cloud Security Day 2024
AWSのエキスパートが語る！AWSセキュリティ構築＆運用における課題とベストプラクティス
-
講演者
- アイレット株式会社: 廣山 豊 氏
- アマゾン ウェブ サービス ジャパン合同会社: 寺嶋 朋子 氏
- クラスメソッド株式会社: 菊池 修治 氏
- 株式会社サイバーセキュリティクラウド: 桐山 隼人 氏(モデレーター）
-
自己紹介
- 廣山さん
- クラウドインテグレーション事業部 MSP 事業の自動化や効率化を行う
- セキュリティサービス設計や提案を行なっている
- 寺嶋さん
- AWS セキュリティコンサルタント
- AWS をどうやって安全に使えるのかを支援する
- 菊池さん
- 自動車メーカーで AWS を触って興味を持って現職
- 桐山さん
- 廣山さん
なぜこれからの時代にクラウドセキュリティが大切なのか
- 廣山さん
- クラウドによって責任共有モデルでクラウドベンダーにお願いできるポイントがある一方、ユーザーで気をつけないといけないところがある
- 寺嶋さん
- 一つの企業で管理する AWS アカウントはどんどん増えている
- それを統一して管理するのはどんどん難しくなっている
- 菊池さん
- クラウド特有のセキュリティインシデントが発生しているケースもあるのでそれを意識する必要がある
セキュリティ強化を目指す際に、組織が直面する課題とは？
- 廣山さん
- セキュリティアラートのオオカミ化
- AWS では GurdDuty 等で簡単に設定できるが、それがアラートを投げすぎて放置されがち
- 上がっていることが当たり前になってしまう
- AWS アカウント内での管理
- 最小権限や退職アカウントが残っている状態だったりする
- セキュリティアラートのオオカミ化
- 寺嶋さん
- 組織、人かなと思う
- アラートが上がったまま誰もみていない、というのはよく見る
- 結局は見る人に左右される、数も質も重要
- どの会社もセキュリティにコストをかけている状態に持って行けていない
- オンプレの時から人は足らなかったかもしれないが、クラウドになったことでより簡単にアプリケーションが構築できるようになった
- 逆にアラートの数やセキュリティ等で検討しないといけない場所が単純に増えている
- 組織、人かなと思う
- 菊池さん
- セキュリティの重要性ややらなければいけないことに対する認識はちゃんと持っている
- が、放置されてしまうところも多い
- 具体的にどう行動に進めるか、が重要
- 取り組むところは大小たくさんある
- 認証情報の棚卸しとかは現場の担当者でもできる
- そうゆうところを積み重ねていくことでセキュリティレベルを上げることはできる
- ここを疎かにするとセキュリティインシデントが発生してしまう
- セキュリティの重要性ややらなければいけないことに対する認識はちゃんと持っている
- 廣山さん
- MSP を最初にやった時はアラート削減
- 1日１０００件以上のアラートを受け取っていた
- Critical アラートとして上がってくるもののほとんどが Info レベル
- これを可視化して認識合わせを行なった
- 今はほぼ上がっていないし、アラートを削減した時に一人一人が意識して対応するようになった
- 1日１０００件以上のアラートを受け取っていた
- MSP を最初にやった時はアラート削減
- 寺嶋さん
- まだ運用をすごく上手にしているのは少ない印象
- うまく対応している企業は専門の人をアサインしている、そして役割をその人自身も周りの人も理解している
- 役割が個人としてもチームとしてもはっきりしている場合にうまく回っているように思うので役割の定義は重要
- ふわっと役割を持っているとうまくいかないケースが多い
- 監視だったらトリアージしてそれを責任もって見る人を決定する、など
- いつ出てくるかわからないアラートをうまくするコツは高望みしすぎないこと
- 自分でできるところを意識してスモールスタートすることで成果が出やすくモチベーションにつながりやすい
- 役割が個人としてもチームとしてもはっきりしている場合にうまく回っているように思うので役割の定義は重要
- 菊池さん
- うまくスケールするコツは風呂敷を広げすぎないこと
- ベーシックにやらないといけないことを認識してここのメンバーでできることをしっかり定義する
- ベースライン（やらなきゃいけないこと）はそんなに変わらない
- やるべきことを知識として共有していくことが重要
- うまくスケールするコツは風呂敷を広げすぎないこと
AWS 環境でセキュリティを強化するための組織体制づくり
- 廣山さん
- セキュリティ、何も起こらなくて当然
- 何も起こらないことを評価できる仕組みづくり
- 何かあった時に報告しやすい風土作り
- セキュリティ成熟度モデルが AWS から出ているのでそれを確認する
- セキュリティ、何も起こらなくて当然
- 寺嶋様
- お客さんがサイバーXXとか、CCoE とか IT 部門とかセキュリティを考える組織は企業によってさまざま
- 一つの会社で一度支援したことが次に同じ会社の別の部署で８割型同じことを支援したことがあった
- 会社としての共有ができれば効率的になったと思う
- 効率化した組織づくりができると良いと思う
- 日本は縦割り文化なので共有が難しいということもあるのかもしれない
- 全体最適の勘所
- 組織横断的な CCoE がある方がいいと思う
- 会社全体の最適解を定義できるチームという感じ
- 組織横断的な CCoE がある方がいいと思う
- お客さんがサイバーXXとか、CCoE とか IT 部門とかセキュリティを考える組織は企業によってさまざま
- 菊池さん
- セキュリティは全ての人に責任がある
- 経営者〜メンバーレベルまで大事
- 経営者であればその部門に投資する
- セキュリティ部門であれば仕組み化を含めて検討する
- 営業やマーケでもパスワードルールなど、ルールに遵守した活動を行う
- 業務上必要な割り振りはしっかりと認識してあげることが必要
- その上で啓蒙し続けることが重要
- 経営者〜メンバーレベルまで大事
- セキュリティは全ての人に責任がある
まとめ
- 廣山さん
- 最近は AI も出て来たりで、よりセキュリティの重要度も上がって来ていると思う
- セキュリティは難しいけど面白みもある
- 他の人の役にたつことを楽しんで自分の組織だけでなく、横断的に働きかけてほしい
- 寺嶋さん
- 組織体制という観点
- セキュリティの組織の名前の種類が多い
- 誰が何の責任を持って何をやっているのかがわからないことで不協和音みたいなのが起こりがち
- 組織体制は一度作って終わりではなく、組織であっても改善できるような組織のあり方を考えていけるといいと思う
- 一発で綺麗なものはできない
- 菊池さん
- 社内のセキュリティとか間違えると事業との対立構造とか出て来がち
- クラメソさんでは「決してブロッカーになるつもりはない、安全に取り組めるようにするための仕組みを作る」と伝えている
- 一緒に事業を作るという意識を持っている
- 取り組みを安全に行うためにサポートする組織
- 桐山さん
- 多くの会社、大きな会社であればあるほど人も足りないし、やらなければいけないことも多い
- 専門家がやるだけでなく、社内全体でやるべきというメッセージがあった
- サイバーセキュリティクラウドもそういったところを支援できるようになっていきたい
IPO準備企業必見！ココナラから学ぶ上場前後でのセキュリティ改革プロセス
-
講演者
- 株式会社ココナラ: 川崎 雄太 氏
- 株式会社サイバーセキュリティクラウド: 渡辺 洋司 氏（モデレーター）
-
自己紹介
- 川崎さん
- ココナラで SRE / 情シス / セキュリティ領域の EM
- SRE Next 2024 のコアメンバー
- 渡辺さん
- CSC の CTO
- 川崎さん
ココナラの事業
- マーケットプレイス
- オンラインでサービスを売買できるスキルのマーケットプレイス
- メディア
- 弁護士マッチング
- エージェント
IPO 前のセキュリティ体制について ~ ココナラのセキュリティの課題について ~
- 上場前のセキュリティはどうゆう状態だったのか
- 一言で言うとリアクティブにしか動けていなかった
- 半年ないくらいに上場した
- インシデントではないがヒヤリハット事例
- 当時共通的なユーザーを共有利用していた
- 悪意ある社員がいたら悪用されてしまう
- 上場前に人単位に権限を絞った
- 悪意ある社員がいたら悪用されてしまう
- 課題の把握が弱く、どの順番で何をすれば良いか？が不明確
- セキュリティに関して後手後手の状態だった
- そもそも「何が課題か？」を正しく認識できていない
- リアクティブ的に発生する課題に対しての対応はしているが、モグラ叩きでしかない
- セキュリティの全体感を捉えて、体型立てた課題対応を推進する役割がない
- セキュリティに関して後手後手の状態だった
- セキュリティエンジニアは不在、兼務で何とか対応
- CSIRT を立ち上げたのは上場から半年経過後
- それまではセキュリティ専門組織はなく、せキィリティエンジニアも不在で、インフラ・SREエンジニアが手の空いた時に対応
- プロダクトのグロースを優先するので、モグラ叩きで手一杯
- 上場を乗り切ることで手段を問わず行なっていた
- ボールが落ちる、のはセキュリティに関わらずありがちだが、 SRE があることで拾われることもあった
- CSIRT を立ち上げたのは上場から半年経過後
- 当時共通的なユーザーを共有利用していた
ココナラが実践した上場前後でのセキュリティ組織構築のための取り組み
- 何ができていて、何ができていないか？の現在地を把握
- セキュリティだけでなく、内部統制・監査の視点を含めて、現時点でどうなのか？をアセスメントしてもらった
- 自社アセスメントは定期的に行なっている
- 最初は外部の人に入ってもらった効果は？
- セキュリティ以外の部分もみてもらえて非常に助かった
- WHY、WHAT を任せて HOW の部分にリソースを避けた
- 最初は外部の人に入ってもらった効果は？
- 自社アセスメントは定期的に行なっている
- アセスメント結果をもとにまずは何から取り組むべきか？を明確化して、対策を推進した
- セキュリティだけでなく、内部統制・監査の視点を含めて、現時点でどうなのか？をアセスメントしてもらった
- 脅威の対策度合いを細分化し、対策度合いを数値化
- 対策度合いを数値で表し、数値が小さい=優先度高と定義
- 例えば、この時点では「DDoS攻撃」や「脆弱性攻撃」の対策が弱み
- この判断の基準を作った時のディスカッションは？
- シンプルに川崎さんと役員の二人でクロスチェックしつつアセスメントした
- 対策としての優先度の判断はどうやった？
- たまたま上場企業にいた経験があった
- どうゆうところが狙われやすいか、みたいな観点を持っていた
- たまたま上場企業にいた経験があった
- 対策度合いを数値で表し、数値が小さい=優先度高と定義
- 対策費用とインシデント発生時の影響を定量で比較
- セキュリティ強化を進めていくためには、経営層の理解が不可欠
- 特にお金の面
- インシデント発生時の対応費 > セキュリティ対策費 という構図を経営層に理解してもらい、体制構築やソリューション導入の予算を獲得した
- 考えたパターンは 5パターンくらい
- 補填費用やレピュテーションみたいなところの事例を集めた
- 最大
- 会員の個人情報を売られてしまった
- 1名あたり500円の補填を行った
- 会員数 x 500円だといくらかかる？
- みたいな感じ
- 会員の個人情報を売られてしまった
- 考えたパターンは 5パターンくらい
- セキュリティ強化を進めていくためには、経営層の理解が不可欠
- セキュリティ責任者採用と組織化で役割分担を明確化
- 採用で検討したポイント
- AWS 側を強化するのか社内情シスを増やすのか
- 社内情シスに振り切ったところからスタート
- AWS の部分は AWS と MTG で強化
- Well-Archtected Tool を軸に検討
- AWS 側を強化するのか社内情シスを増やすのか
- 採用で検討したポイント
| グループ名 | チーム名 | 役割 |
|---|---|---|
| システムプラットフォームグループ | インフラ・SREチーム | AWS アカウント分離、IAM Role 整備 |
| 情報システムグループ | CSIRT チーム | 攻撃対策ソリューション導入、アクセス権限精緻化 |
| CIT チーム （情シス） | 新デバイス・OS 検証導入、アクセス権限精緻化 |
企業を成長させるためのセキュリティ組織のポイント
- 上場前に焦って付け焼き刃になるのはNG, 地に足をつける
- どのようなプロダクト・サービスを提供している会社でも「セキュリティ対策」は必須
- 必要に迫られてから実施するのではなく、あらかじめ実施が必要なタスクとして見込んでおくことで、焦って優先度の低い対応に時間を取られないようにすることが重要
- 時間がないからこそ、本当にやるべきことにフォーカスする
- セキュリティ対策に使えるリソース（予算・工数など）は限られるので、取捨選択をすつつ、効率的・効果的に対策を進めることが重要
- 手当たり次第に対応していくのは悪手なので、緊急度ｘ影響度で優先度を見極めて、一つ一つ対応していく
- セキュリティ対策に銀の弾丸はない
- 放置すると陳腐化するので放置しないことが大切
- 攻撃や脅威は日々進化している
- 一度セキュリティ対策をして終わりではなく、継続したリファクタリングを行う必要がある
- ソリューションは「導入する」よりも。「導入後の運用」が大事
- リアクティブな対応だけでなく、「プロアクティブ」な仕掛けが重要
- ログの分析をすることによって1日あたりのアクセス数の伸びに気づける
- 増強のポイントとか先手で対応できる
- ログの分析をすることによって1日あたりのアクセス数の伸びに気づける
ENECHANGEが実現した管理者の工数負担を削減しながらもAWSセキュリティを強化した方法とは
-
講演者
- ENECHANGE株式会社: 岩本 隆史 氏
-
自己紹介
- 現職は VPoT
- 全社的な技術施策の提案 ~ 実行
- 前職 AWS Japan
- クラウドサポートアソシエイト
- 現職は VPoT
-
ENECHANGE について
- 3つの事業
- 電気自動車の充電サービス
- 電力ガス会社切替サービス
- 電力会社向けシステム開発
- 3つの事業
-
セキュリティ強化の背景
- シングルアカウントで 200弱の環境 （本番開発まで同じ環境）
- Elastic Beanstalk を使って 96
- ECS に移行中
- クラスター ８５
- CTO 室の数名でインフラを担当
- ２〜4名
- アプリケーションの脆弱性診断は外部委託
- 入社時点では GuardDuty のみしよう
- Trusted Advisor
- Security Hub
- WAF
- 等は使っていない
- セキュリティ強化がタスクの一つに
- インフラ構築・運用
- SRE
- コスト最適化
- 開発者体験工場
- 全社的な技術レベル向上
- ブランディング
- ここにセキュリティが追加された
- シングルアカウントで 200弱の環境 （本番開発まで同じ環境）
-
具体的な取り組み
- IAM ユーザーの棚卸し
- アクセスキー不使用がベストプラクティス
- IAM Role を使用する方に動いた
- 使われていないユーザーを削除
- １年以上アクセスのないユーザーを洗い出して削除
- EC2 の IAM ユーザー利用を廃止
- 環境変数で IAM ユーザーを指定していた
- Role ベースの認証に切り替え
- アクセスキー不使用がベストプラクティス
- CircleCI を OpenID Connect に移行
- CircleCI も OIDC に対応したので IAM Role 化
- ChatOps を導入
- EC2 起動専用アクセスキーを見つけた
- エンジニアではない担当者が AWS CLI で開発機を起動している
- そのためだけに作られたアクセスキー
- 起動のタイミングは不定期
- ChatOps に切り替え
- EC2 起動専用アクセスキーを見つけた
- Trusted Advisor の活用
- セキュリティのみならず Well Archtected に合わせた提案をしてくれるツール
- 当初から有効化されていたが誰も見ない
- 活用方法
- ELB セキュリティポリシーを更新
- 廃止されたランタイムの Lambda 関数を更新
- IAM のパスワードポリシーを設定
- セキュリティのみならず Well Archtected に合わせた提案をしてくれるツール
- Security Hub の有効化
- セキュリティチェックの自動化とセキュリティアラートの一元化
- AWS 基礎セキュリティのベストプラクティスで確認
- CRITICAL： 16件
- HIGH: 819件
- 発見された
- 2ヶ月弱で「重要」と「高」をゼロに
- VPC のデフォルトセキュリティグループを削除
- インバウンド、アウトバウンドルールがザル
- これだけでかなり減った
- VPC のデフォルトセキュリティグループを削除
- Slack への通知を開始
- ゼロにしてから開始しないと通知が延々と通知が来ることになる
- 通知が来たら対応
- tips: AWS Config の利用は倹約的に
- リスクとのトレードオフだが日次記録に切り替えた
- リアルタイム通知を捨てて日次に変更
- オーバーライド設定がないと全サービスを見てしまう
- Security Hub で除外しているものを手作業で Config からも除外
- AWS ドキュメントに公開されているのでそれを突き合わせて設定
- リスクとのトレードオフだが日次記録に切り替えた
- AWS WAF + WafCharm の導入
- 一部で「攻撃遮断くん」を利用
- 人数も少ないので自動化サービスの利用が前提
- WafCharm の導入を決定
- もともと CSC 社製品を利用していて信頼があった
- 現在では 10件に適用している
- 基本的に LB, CloudFront が１件
- 一部で「攻撃遮断くん」を利用
- IAM ユーザーの棚卸し
-
今後のセキュリティ強化に向けて
- Well-Archtected レビューの実施
- セキュリティだけでなく信頼性の柱とか
- マルチアカウント戦略への移行
- 一番最初に出てくる項目
- Well-Archtected レビューの実施
-
まとめ
- 強化方法 = ベストプラクティスの適用 ＋ 自動化
- IAM ユーザーの制御
- Trusted Advisor の活用
- SecurityHub の有効化
- AWS WAF + WafCharm の導入
- Well-Architected レビューの実施 << 今後
- マルチアカウント戦略への移行 << 今後
- 強化方法 = ベストプラクティスの適用 ＋ 自動化
リソース不足でもAWSのセキュリティ強化＆効率的な運用を実現！WafCharmとCloudFastenerのご紹介
-
講演者
- 株式会社サイバーセキュリティクラウド: 山本 純 氏
-
会社紹介
- クラウド型WAF
- 攻撃遮断君
- WAF 自動運用サービス
- WafCharm
- AWS WAF ルールセット
- AWS WAF Managed Rules
- AWS 環境フルマネージドセキュリティサービス
- CloudFastener
- 脆弱性情報・管理ツール
- SIDfm
- 脆弱性確認・検証
- 脆弱性診断サービス
- クラウド型WAF
-
Webサイトから個人情報を守る
- Web アプリケーション層を守る AWS WAF
- 課題
- ルール作成
- 最適なルールの作り方がわからない
- 網羅性
- WAF運用専任の人材を用意できない
- アップデート
- 新規脆弱性の情報がわからない
- ルール作成
- 課題
- WafCharm
- ログを分析しながらルールを自動で適用してく
- 専任の人材等が必要なくなる
- 強力な防御性能
- 改竄検知機能を搭載
- ログを分析しながらルールを自動で適用してく
- 工数削減イメージ
- おおよそ 75 ~ 80% 程度の工数を削減できる
- 導入件数は国内１
- Web アプリケーション層を守る AWS WAF
-
包括的な AWS のセキュリティ対策を実施するには
- セキュリティサービスは有効化するだけでなく、運用することが重要
- セキュリティについて深い知識を持つ人材がいないので社内で全て対応するのは難しい
- とはいえ、セキュリティ人材の採用は難しい
- 現状の体制では工数の負荷がかかっている
- マネージドサービスの活用
- 高額になることもあるので市場に浸透することもなかった
- CloudFastener
- インシデントアラートを集約し、 CSC の TAM が連絡してくれる
- 24*365 体制で対応
- 最新のルールアップデートに対応
- コンサルティング
- Managed Security Service
- インシデントアラートを集約し、 CSC の TAM が連絡してくれる
- セキュリティサービスは有効化するだけでなく、運用することが重要
Discussion