じゃあ、おうちで学べる

思考を呼び覚ます このコードに、君は抗えるか。

「セキュア・バイ・デザイン」を読んで自分が何番目の豚かを考える。

このエントリーは 3-shake Advent Calendar 2022 2日目の記事です。 前日は@koki_develop さんによるStep CI で手軽に API をテストする でした。

Step CIAPI をテストするためのシンプルなオープンソースコマンドラインツールです。「第8章: セキュリティを意識したデリバリ・パイプライン」ではStep CI のようなツールを用いてデリバリ・パイプラインで正常値、境界値、異常値、極端値を検査することが推奨されています。

qiita.com

このエントリーで言いたいこと

  • セキュア・バイ・デザイン という書籍の多様さ

    • セキュリティにおける設計の大切さ

    • 現代におけるセキュリティの幅広さと難しさが凝縮された一冊であるということ

    • セキュリティを面で捉える難しさと重要性

このエントリーを書き始めた理由

2022年12月7日20:00- よりOWASP Fukuoka Meeting #9で「セキュア・バイ・デザインの鳴くところ」というタイトルで登壇してきます。この発表ではセキュア・バイ・デザイン、シフトレフト、DevSecOps は何すればいいんだよ! という人に対してOWASP SAMM version 2を軸にガバナンス・設計・実装・検証・運用でのロードマップを明確にして設計・実装に関してもいくつかのTipsに言及していこうと思います。このイベントはYouTubeなどで後から動画を公開しないので動いてる私が見たい場合には参加登録してほしいです。発表の動画は公開されないですが資料は公開する予定です。それに対する予稿的な意味合いで書き始めました。内容は違うのに...。

目次

はじめに

セキュア・バイ・デザイン 安全なソフトウェア設計OWASP TOP 10のような既知の脅威をリスト化して問題のある実装に対する解法を実装に組み込むためのTips を紹介する書籍ではありません。開発中にセキュリティについて意識する必要はないというような主張をする書籍でもありません。また、ドメイン駆動設計(Domain-Driven Design: DDD)を用いて、設計する書籍なのでDDDで開発しないから関係ないというわけではないです。システムの設計時にセキュリティだけを切り出して別問題として考えるのではなく、システム全体の関心事として扱い、設計時に考慮するというような書籍です。

「セキュア・バイ・デザイン 安全なソフトウェア設計」の目次

セキュア・バイ・デザインについて実例と共に見ていく導入編。ソフトウェアの作成におけるセキュア・バイ・デザインの基盤を構築する設計の原則、考え、コンセプトについて学ぶ基礎編。レガシー・コードの改善、モノリシック・アーキテクチャでよく起こる問題、マイクロサービス・アーキテクチャについて学ぶ応用編の3部構成になっています。

第1部: 導入編
第1章: なぜ、設計がセキュリティにおいて重要なのか?
第2章: ちょっと休憩: 『ハムレット』の悲劇
第2部: 基礎編
第3章: ドメイン駆動設計の中核を成すコンセプト
第4章: 安全性を確立する実装テクニック
第5章: ドメイン・プリミティブ(domain primitive)
第6章: 状態の完全性(integrity)の保証
第7章: 状態の複雑さの軽減
第8章: セキュリティを意識したデリバリ・パイプライン
第9章: 安全性を考えた処理失敗時の対策
第10章: クラウド的考え方によるメリット
第11章: ちょっと休憩: 保険料の支払いなしに成立してしまった保険契約
第3部: 応用編
第12章: レガシー・コードへの適用
第13章: マイクロサービスでの指針
第14章: 最後に:セキュリティを忘れるべからず!

僕たち二番目の子豚

家を作る時には壊れにくく、泥棒に盗まれにくい家を考えるのは当たり前です。家のセキュリティにコストをかける必要性は有名なの子豚が教えてくれたとおもいます。開発者はビジネス・ロジックを実装に落とし込みながらセキュリティの脆弱性についても考えなくてはならない。しかし、実装の優先するあまり一番目の子豚のような実装を行ってしまいます。そんな人たちを笑う二番目の子豚もいます。実装を行う開発者は常にセキュリティに関するスペシャリストというわけではないです。それを求めることも現実的ではありません。そのため、WAFを入れたり、脆弱性診断を行ったりします。しかし、それらも絶対ではありません。特に二章の"ちょっと休憩: 『ハムレット』の悲劇"で紹介された。ECサイトで「-1個」購入できるようになってしまうようなインシデントに関する話に関してはWAFがちゃんと設定されてないと無力だったりもする。ちなみに全体を通してセキュリティを意識しないことが大事だというが最終章の14章では全く逆のセキュリティを意識する重要性について説明されている。

良い設計と悪い設計の違い

全員にレベルの高いセキュアコーディングを要求するのではなく設計に意識を向けることで、従来のアプローチで抱えていたいくつかの問題に関して解決することを目的にしております。特に3-7章に関してはドメイン駆動設計を行う時にこれを意識しない場合にはこういうような脆弱性に繋がるという例は豊富でかつ示唆に富んでいる。また、本書はドメイン駆動設計から言葉、概念を拝借してはいるが"正しい使い方を簡単に、誤った使い方を困難に"ということを設計で達成しようぜと終始言ってるだけな気もする。あくまで私の感想ですけど。

SREは8章から10章が必読

SREという単語を利用したがこの文章も例に洩れずポジショニングトーク的にSREという単語を利用しておりますので何も言わないでください。SREコンサルという仕事をしているとSREの意味的なゲシュタルト崩壊を起こしてしまいます。情報セキュリティの3大要素にも入るぐらいなのでセキュリティにおいて可用性は重要です。8章から10章は特に私のようにSRE的な仕事をしている人間からするとアイデアの宝庫です。特に大事だと思ったのは使用しているツールのデフォルトの振る舞いを知ることの重要性についてです。既存のシステムで利用している秘伝のタレを継ぎ足しているだけで詳しくなったような気持ちになる。危険。本当はもっと、フォーカスしたいのでここは別でブログ書きたい。ちなみにOWASP Fukuoka Meeting #9のイベントではこの辺が話の中心に添えられている。

3部から読んでも良いと思った

防御的プログラミングのように良識あるようなTipsの積み重ねで問題発生を事前に防ごうというコーディングスタイルがあります。3部はわりとそれに近い内容に関する言及でレガシーコードとマイクロサービスでの注意点や改善方法がまとめられている。レガシーコードに関しては私の大好きなリファクタリング(第2版): 既存のコードを安全に改善するという書籍がある。もう、1章を追加するならセキュリティの概念を足したようなこの章が追加されてほしいと思いました。マイクロサービスの章に関しては現在、私がソフトウェアアーキテクチャ・ハードパーツ ―分散アーキテクチャのためのトレードオフ分析という書籍を読んでいる。セキュリティ的な品質をソフトウェアの設計へ落とし込むには設計段階で考慮が必要。特に非機能的なので熟考に次ぐ次ぐだけ絶対にどうにかならず経験が必要な領域。最終章は具体的なコードレビューやアーキテクチャレビューにセキュリティの専門家が必要な重要性、脆弱性診断やインシデントハンドリングなどのセキュリティをがっつり意識した内容です。全てをひっくり返す感じがしてとても気持ちが良い。セキュリティの専門家はこの章まで耐えて「気持ちぃいいいいい(実際にどうなるかは知らない)」を経験してほしいです。

さいごに

あまねく全ての開発者に対してセキュリティの専門家と同等の知識が求められセキュリティに関する知識を常にアップデートしなければならないというこの時代。 結局、安全な設計にもセキュリティにもお金が必要になる。地獄の沙汰も金次第。ちゃんと、コストを支払える会社に入社を果たし三番目の豚として幸せな生活をおくれるように祈ってます。 本書は本当に良い本なのでこのエントリーで気になった人はぜひ、セキュア・バイ・デザイン 安全なソフトウェア設計を購入して熟読して実践してほしいです。

明日は我らが長ATSによるSRE事業をしているので「信頼性」について考えたくなったです。

参考