2023年6月14日から15日にかけて、日本CTO協会が主催するカンファレンス「Developer eXperience Day 2023」が開催されました。さまざまなテーマのセッションがおこなわれたなかで、本記事ではセキュリティ施策によるエンジニアの開発者体験向上をテーマにしたセッションの内容をお届けします。
セッションには、株式会社Flatt Securityで取締役CTOを務める米内貴志氏が登壇。その模様をお届けします。
米内貴志（よねうちたかし）氏
株式会社Flatt Security 取締役CTO
2019年、株式会社Flatt Securityに入社。2021年6月よりCTOに就任。Web開発者向けセキュリティ教育「KENRO」や、テック組織向けクラウド堅牢化サービス「Shisho Cloud」の開発運用に従事。著書に『Webブラウザセキュリティ』（2021年、ラムダノート社）など。
目次
プロダクトのリスクマネジメント施策
この時間は「開発者体験をむしろ向上させるセキュリティ施策のイロハ ― Policy as Code の理論と実践」ということで、Flatt Securityの米内から発表します。
最近はデベロッパー向けのブログ記事などを出しているので、社名を見たことがある、という方もいらっしゃるかもしれません。弊社Flatt Securityはデベロッパーがセキュリティまわりのことに足を取られずに、生産性向上ができる支援を行っている会社です。
今回聞いてくださっている皆さんは、プロダクトのアーリーフェーズで関わっている方もいらっしゃるでしょうし、複数のプロダクトで複数のフェーズに関わっている方もいらっしゃるでしょう。
プロダクト開発におけるアーリーフェーズにおいては、草の根的な、ボトムアップなセキュリティ施策が行われます。たとえばCI/CDパイプラインでセキュリティチェックのLinterや静的解析をおこなうなどです。TerraformのコードにもLinterをかけているので、ある程度インフラセキュリティもOKです、という組織もあるかもしれません。
こうした施策を行いながらプロダクトのフェーズが進んでいくと、プロダクトに対してより多くのお客さんがついたり、内部・外部監査が入ったりするタイミングがやってきます。セキュリティに関するストーリーを説明し、信頼される事業である、安心して使えると判断してもらう必要があります。
この段階になると、CIパイプラインでセキュリティチェックツールが走っていますよ、という説明では足りなくなる場合があります。ほんとうに全てが Terraform で管理されているのか？といった具合にですね。セキュリティは最も弱いところにリスクが引っ張られるため、より幅広な視点で残存リスクを把握しなくてはなりません
セキュリティリスクマネジメントと開発者体験
ここで、セキュリティ施策の構造について、考えてみましょう。話を簡単にするために、実務上の込み入った話というより、まずは教科書的な話からスタートしてみます。
多くの場合、まず意識するべきは、自社の組織や事業に求められるセキュリティレベルがどの程度かという点です。具体的には国際規格・法規制・業界規格など、外から求められるものを把握し、自分たちが何に対応すべきかを考えます。PCI DSS のような取り扱い情報からくる制約や、業種や事業展開するマーケット特有の規制を洗い出してみましょう。
次に、自組織はセキュリティに関してなぜ・何をやるのかの基本方針を定義します。
自分たちがセキュリティについてどう考えてどのような施策をおこなうのかを示す、ビジョン・ミッション・バリューのような位置づけのものを整理していく、というイメージです。
次はベースラインを定義します。
自社が守らなければならない基準に合わせ、顧客情報はこう扱いましょう、など最低限守るべきルールを設定します。ここは骨が折れる作業ですが、実際に何をどう守るのかを規定していく、大切なプロセスです。最終的には、これらを実現するための業務フローなど、ガイドライン・推奨事項を作っていきます。
このような規定群の定義を進めつつ、その後はリスク管理がうまく回っているかどうかをアセスメントや監査などを通じて判断します。残存リスクを確認しながら、規定群自体の改善や、リスクの低減を進めます。
これが基本的、教科書的なセキュリティリスクマネジメントの構造です。
セキュリティリスクマネジメントの開発者体験
ここで、セキュリティリスクマネジメントを“つくる”側の開発者と、受ける側の開発者、それぞれの視点での開発者体験について考えます。
セキュリティリスクマネジメントを作る開発者の体験
まずはセキュリティリスクマネジメントをつくる人の立場で考えてみましょう。
実際弊社では様々な企業さんとやりとりをする中で、アセスメントの自動化の難しさに直面しています。
それは、自動化に取り組む際に、どうしても自然言語からソフトウェアへの面倒な変換が入るから、というのが主な理由です。
作成したガイドラインに則って評価を行う場合、自分たちで定義した自然言語のルールをもとに、各種ツールを用いた現場業務のフローがルールを満たしているか、をチェックすることになります。
そのためには、たとえば自然言語で定義したガイドラインと、実際の AWS の設定の適正値をうまく紐づける必要があるかもしれません。これらは非常に手間がかかり、かつ自動化がしづらい部分になります。
しかし、手間がかかるからといって、社員にチェックリストを配布して確認業務を移譲し、人手を以て実施してもらえばいいかというと、本当にそれでよいのか疑問が残ります。
また、こうしたチェックのプロセスを半年に1回などの頻度で実施していったとしても、なかなか社員が対応してくれなかったり、時間がかかったりします。
結果として、セキュリティリスクに関する状況が改善していきにくい、という面があります。自然言語によるポリシー運用の辛み、自動化の辛みが、受け手も含めたリスクマネジメントの停滞を招くという悪体験があるわけですね。
セキュリティリスクマネジメントを受ける開発者の体験
一方でセキュリティリスクマネジメントを受ける側にとっての体験は、つくる側の体験の裏返しになります。
例えばつくる側のアセスメントの自動化という悪体験は、受け手側から見れば、「今言われても・・・」といった遅れたタイミングでフィードバックが行われることによる悪体験に直結しています。
その他にも、守るべきルールがわかりづらかったり、なぜ守るべきなのかが分からないなど、全体的に開発者体験がよくないのが実情です。
開発者体験を向上させるセキュリティ施策
ここまではセキュリティ施策を設計するうえでの大変さについて話をしてきましたが、ここからは大変さを乗り越える挑戦について話をしていきます。
挑戦1 継続的検査・監査実現のためのPolicy as Code基盤の実装
先ほどは、セキュリティ施策のアセスメントの自動化が難しいゆえに、改善スピードやリスク低減が遅くなりがち、という話をしました。
そこで最近よく聞くようになった概念が、Policy as Codeです。
これは、従来自然言語で書かれていたセキュリティポリシーや社内のポリシーを、コード形式で表現するものです。
Policy as a CodeのメリットはIaCなどと一緒で、機械判読である、すなわちチェックを機械的に取り扱えるという点です。たとえば、現状のAWSリソースの設定が自社のポリシーを満たしているかどうかを、コンピュータでチェックする、といった自動化の土台になります。
自然言語で管理されたチェック項目を開発者に半年に1回確認してもらう、というやり方では、受ける側にとっても面倒です。
その反面コード化することでGitなどで管理できるようになり、レビューやデプロイやテストなど、さまざまな点で自動化の可能性が生まれます。結果として、高頻度に・自動的にセキュリティリスクを評価可能になり、セキュリティリスクマネジメントのアジリティ向上に繋がることが期待できます。
と、ここまでは Policy as Code というコンセプトの理想的な活用方法の話になります。
実際にはポリシーをただコードに変換すればいいわけではなく、さまざまな課題があります。たとえば、ポリシーで検査・監査する対象のデータの取得などは、ただ自然言語のポリシーをコードに変換する過程で、さまざまな部分を実装しなければなりません。
そのほか、実行する場所・ランタイムや実行頻度・タイミングを決めるなど、自社のセキュリティポリシーを単純にコード化できたとしても、まだまだ考慮すべき点が残ります。
こうした、コードへの変換やそれに伴うさまざまな実装・運用が発生するとなると、結局Excelチェックシートを配るほうが楽だよね、専任者の採用難易度を考えるとサステナブルだよね、という結論になる組織もあることでしょう。とにかく理想形を目指すハードルが高く、ずるずると低い開発者体験を受け入れざるを得ない状況が招かれやすいのです。
そこで、現在弊社で初期ユーザ様からのフィードバックを受けながら展開しているのが、Shisho CloudというPolicy as Codeを実現するプラットフォームです。
自社のセキュリティルールを自然言語からポリシーコードに落とす部分をやっていただければ、実行タイミングやデータの取得といったややこしいところをShisho Cloudが担うことができます。
また、チェックの結果をダッシュボードで確認することも可能です。真に自社のセキュリティポリシーとして妥当なものを模索する、というプロセスに集中いただける、ということです。
こうした基盤を導入していただくことで、アジリティが高い状態でセキュリティリスクマネジメントをおこなえます。
挑戦2 より多くの”コンテキスト”をユーザーへ届ける
ここまでの話で、Policy as Codeのコンセプトにならって、セキュリティポリシーに基づく検査・監査を自動化する説明をしました。ここからは更に一歩進んだ施策実施の話をしたいと思います。
前提として、自動化した結果、だいたいの組織では思っていたよりアラートが出ることになります。そして、アラートに対応するのは簡単ではありません。これはどの組織にも共通するお悩みです。
そんな中、うまくいっている会社さんが優れているのは、問題に対して「なぜこれが問題なのか」についてのコンテキストが上流のストーリーとの接続とセットで組織に伝えられている点です。そのため、発生している問題がどの程度の問題なのか、をきちんと判断できます。
この点についてShisho Cloudという製品では、さまざまなコンテキストを検査時に取得できる情報として盛り込む、ということに取り組もうとしています。
たとえば「そもそもこれはアクセス経路が非常に限られたのリソースだから、現実的なリスクは低めなはず」とか、「強い権限を持ったIAMロールが関連しているから、優先的に対処が必要」など、実際のリスクレベルが判断・対応しやすい環境をつくろうとしています。
また、セキュリティリスクマネジメントのプロセスを自動化するだけではなく、その結果を実際にアプリケーション作っている方々に早期にフィードバックすることが大事です。
Shisho Cloud においては、ダッシュボードで、優先的に対応するものを表示したりなど、ポリシーをコード化した次のステップを支えるべくアプローチしています。
セキュリティのいい施策には、リスクマネジメント施策自体にいいアジリティがあります。その上で、適切なコンテキストとともに組織にフィードバックしていくことで、ステークホルダーの対応力、リスクマネジメントの受け手側のアジリティが高まっていく、ということです。
キーワードはアジリティとコンテキスト
今回はセキュリティリスクマネジメントについて、つくる側と受ける側それぞれの開発者体験を阻害する要因と、解決策としてのPolicy as Code、そしてその基盤となるShisho Cloudという製品についてご紹介しました。
ここでのキーワードは
- アジリティ
- コンテキスト
です。
セキュリティリスクマネジメントのプロセス自体のアジリティを高めること、十分なコンテキストをもったフィードバックを組織に行うこと。これにより、開発者体験の高いセキュリティリスク管理に取り組めるのではないかと思います。
今回のセッションではPolicy as Codeという言葉だけでも覚えておいていただけると嬉しいです。またこのような取り組みに興味があれば、弊社にもお気軽にお声がけいただけたらと思います。本日はありがとうございました。
執筆後記
セキュリティリスクマネジメントに関する基本構造や、Policy as Codeという考え方やそのメリットについて、非常にわかりやすく説明されていました。
セキュリティポリシーに則っているかのチェックなどは、多くのエンジニアの方が受ける側として経験したことがあるのではないでしょうか。やはりどうしても面倒に感じられる部分ではあるため、そこから効率化して開発者体験向上に繋げられるというのは、すばらしいですね。
（文：伊藤由貴）
