目次
■クラウド＆インフラストラクチャ
2022.05.12 2024.03.06 約4分
Forkwell が主催する技術イベント「Infra Study」。今回のテーマは「インフラとセキュリティとこれから」です（開催日：2020年 9月25日）。本記事は登壇者の森田さんの基調講演からクラウド時代のセキュリティで意識すべき点や、GMOペパボ株式会社がセキュリティ対策で意識している点を紹介します。Q&A ではまつもとりーさんを交えて視聴者からの質問に回答しているので、是非ご覧ください。
攻撃に対してどう守っていけばいいのかを考えます。
クラウド時代のセキュリティで意識すべきことは、責任の共有だと思います。どこまでクラウドプロパイダーが面倒を見て、どこからは自分たちで守らなければならないのか。
マネージドとはいえども、Kubernetes はセキュリティを全部見てくれるわけではないため、自分たちでどこまでやるのかをあらためて確認する必要があります。
Kubernetes などの基盤周りの技術は進化が早いため、セキュリティ対応が求められたタイミングで、最新バージョンに上げてくださいといわれても最新バージョンと差異が生まれることがあります。
また、セキュリティに関するガイドラインはないため、サービスによってセキュリティレベルがまちまちで、足並みが揃わないこともあります。
そういった問題に対処するために、DevSecOps を取り入れるところも多いと思います。
しかし DevSecOps はツールを入れただけでは解決するものではなく、むしろセキュリティの文化を作っていく必要があるでしょう。
開発現場でテストを書くことは、当たり前になっていますが、それも一種の文化です。セキュリティの対応が当たり前になる文化を作り、それを醸成していく必要があると考えています。
文化を作るのは非常に難しいので、組織に合ったアプローチがあります。たとえばガイドラインを作り、共有モデルを構築することで、あらためて自社サービスの脆弱性を洗い出すことができます。
また、定期的な外部からの脆弱性診断を実施するだけでも、セキュリティを意識するようになるので、そこから始めていくといいです。
ただ、それだけではセキュリティのために、手間が増え、スケールしない点もあるため、複雑さを抽象化するために自動化をおこなうなど、基盤作りが大切です。
当社、セキュリティ対策室のコンセプトである3つのCは以下の意味を持ちます。
コミュニケーションをとりながらセキュリティ対策を継続し、達成しましょうと意識しながら業務をおこなっています。
最後に Test Driven Security、略称 TBS と呼ばれるものがあります。セキュリティチームが開発運用のサイクルのなかで基準を満たしているかをチェックします。積極的に開発サイクルのなかにセキュリティを取り入れていくのがいいと思います。
Q＆A
森田：たとえば GitHub の CI であれば、それに環境変数として渡す機能があるので、それを利用することがベストプラクティスだと思います。
また Kubernetes のような環境だと、シークレットリソースのマニフェスト自体を暗号化する必要があります。外部の HashiCorp Vaultや KMS から取得する形になると思います。
まつもとりー：コンテナ環境だからこそ、扱いの変わるものが今後出てくるかもしれないですが、今のところは同じ印象がありますね。
森田：自社サービスのセキュリティポリシーを決めるときは、リスク分析のフレームワークを使っています。
リスクのフレームワークによっては、これぐらいの人たちに影響があれば、リスクレベルが5点といったマトリックスがいくつかあります。その合計で最終的なリスクの点数を出します。
たとえば、リスクが high 以上は即時対応であったり、リスクが低ければ、2週間といったように、最低でも何日以内に対応するかを決めています。
顧客に影響を与えるセキュリティの誤検知を許容するかに関しては、できるだけ影響を小さくしたいですが、カバーできない問題はどうしても出てくるので、テスティングやステージング環境でしっかりと確認するようにしています。
また、セキュリティの誤検知に起因してエラーが発生しているかをモニタリングする必要もあります。
まつもとりー：顧客に影響を与えるセキュリティの誤検知とは、明らかなシグネチャマッチもあれば、ある程度予測的なパターンも含め、どの辺まで許容できるかという意味での誤検知なんですね。
森田：セキュリティをやっている人たちの Twitter をフォローし、メーリングリストのフィードを片っ端から取得していますが、やはり重要なのは、手を動かすことだと思います。
実際に手を動かさないと、うまく動かないであったり、ちゃんと攻撃できるのかといったわからない部分があるので、それが一番意識してやっている勉強法です。
あとはアンテナの範囲を広く持つことが大切だと思います。どのセキュリティ分野にもある、応用分野だと思うので、そこにアンテナを持つことが必要です。
まつもとりー：今はだいぶセキュリティの知識も付いて、詳しいからこそ興味を持ってやれていると思いますが、森田さんの場合、セキュリティに興味を持ち出したきっかけはありますか？
森田：きっかけは、 CTF（Capture The Flag)というセキュリティのゲームですね。CTF をやったことでセキュリティだけでなく、コンピュータサイエンスや、その辺りの深い知識も学べました。セキュリティは何かの分野の応用なので、基礎知識をゲーム感覚で学べるのは僕にマッチしていました。
まつもとりー：そういう入り方をしてみることが、いいかもしれないですね。おもしろいと思ったら積極的にやる。手を動かすのにも、合っていますね。
森田：当社もまだ醸成をしている途中ですが、自分が入社したときはすでにセキュリティに対して意識のある方が多かったので、ゼロからどう醸成するかについては、少し答えづらい質問です。
ただ、醸成するための活動として、当社だと Pepabo Tech Friday といって月に1回エンジニアたちが集まって、その月にやった自分の活動をアピールする場があります。
僕はそういった場で自分たちが作ったツールや仕組みを積極的に共有するのが重要だと思います。
まつもとりー：実務ではサービスを作っている人や、インフラもやっている人、Webアプリケーションを作っている人がいるなかで、この辺のセキュリティも見てほしいなどの要望や、何か脆弱性が報告されたときに意識してるコミュニケーション。そういった忙しい相手との関わり方など何かありますか？
森田：セキュリティーチームが開発の現場にいると、対立しがちです。この問題はどの組織でもあると思います。
そこで Co3 のコミュニケーションの部分は、すごく気を使っていて、たとえば脆弱性を修正してくださいと情報を渡すだけでも、CV番号やバージョンだけを投げるのではなく、どういう場面で発火するのかまでを調べて、提供することを心がけています。
また、バージョンアップに事情があってできません。となったときは、緩和策まで出すところも意識しています。
まつもとりー：コミュニケーションを取りながら、できるところまでしっかりサポートするのが素晴らしいですね。
森田：制度やルールの運用でいうと、まずはガイドラインを作ります。たとえばDevSecOps でいうと、その開発者のセキュリティ知識の底上げなどが必要です。年に1回はセキュアコーディング研修を実施して、セキュリティ知識の底上げもしつつ、意識を高めています。
さらにインシデントが起こったときは、インシデントに関係する人が現場の開発者だけでなく、実際には CS やマネージャー、あるいは CTO や CEO 辺りの人たちも関係する事象です。
どこにブロードキャストするかや、どれぐらいの情報量を伝えるのかを気をつけながらガイドラインを作り、それに基づいてコミットしていくことを常に心がけています。
まつもとりー：ガイドラインに従いつつも、ある程度セキュリティ対策室でやれる技術的なツールやフレームワークは、しっかりこちらで作る。またコミュニケーションにおいても、しっかり相手のことを考えて、うまくバランスとりながらやっているわけですね。
森田：セキュアコーディング研修も、セキュリティ知識の底上げの一環です。またセキュリティキープアップというものもあって、各サービスでセキュリティ対応をしたい部分に、どれぐらいコミットしているかを定期的にみています。
まつもとりー：セキュリティ対策室として一緒に取り組んでいくことで、それを継続すれば、みんなが協力してやれているんですね。技術的なアプローチ以外のコミュニケーションの大切さを感じました。
Forkwellは「成長し続けるエンジニアを支援する」をコンセプトに勉強会を開催しています。Infra Study Meetupは、インフラ技術の「これまで」と「これから」を網羅的に学ぶイベントです。インフラ技術の各分野に精通した講師を招いた講演や著名エンジニアによる発表を実施しています。
当記事に掲載されている全ての情報は、イベント実施日時点の情報であり、完全性、正確性、時間の経過、あるいは情報の使用に起因する結果について一切の責任を負わないものとします。
