読むのがホネな(積みがちな)技術書やビジネス書を取り上げて2週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第39回。常時、けっこうな量の積読があるのだけれども、知り合いと読書期日を約束することによって消化が捗るという仕組み。ここ最近はこんな本を読んでいる。
- #38 「Team Topologies」後半読んだ #デッドライン読書会 - 勘と経験と読経
- #37 「Team Topologies」前半読んだ #デッドライン読書会 - 勘と経験と読経
- #36 「恐れのない組織」読んだ #デッドライン読書会 - 勘と経験と読経
- #35 「リーン・エンタープライズ」後半も読んだ #デッドライン読書会 - 勘と経験と読経
- #34 「リーン・エンタープライズ」まず前半を読んだ #デッドライン読書会 - 勘と経験と読経
さて、今回のお題は「セキュア・バイ・デザイン」である。
だいぶ歯応えがありそうなので、3回に分けて読む予定。この記事は1回目「序文~第5章: ドメイン・プリミティブ(domain primitive)」までを読んでの感想になっている。
本を読む前に:そもそも「セキュア・バイ・デザイン」って?
今回取り上げる「セキュア・バイ・デザイン」の書名は時々耳にする本というくらいしか知らなかったのだけれども、ちょっと改めて調べてみた。
- 類似する用語で「セキュリティ・バイ・デザイン(Security By Design:SBD)」という概念があるが、こちらはより包括的な概念のようだ。
- 「情報セキュリティを企画・設計段階から確保するための方策」(NISC)
- 関連する概念で「セキュアコーディング」というものもあるが、当然これとも違う
で、本書であるが概説はこのようになっているんだけれども、
プログラミングの質を高めることで、セキュリティを向上させることができる― 著者らの考えを様々な形で試し検証を行い、本書「セキュア・バイ・デザイン(Secure by Design)・安全なソフトウェア設計」にまとめました。
うーん、この文章の説明はなかなかに難しい。
まだ全てを読み終わっていないのだけれども、現時点での私の「セキュア・バイ・デザイン」に関する理解はこのようなものだ。
- システム設計時にセキュリティだけを切り出して考えるのではなく、システム全体の関心事として取扱い、あらゆる設計時に考慮する。
- ドメイン駆動設計を利用している場合を想定して、具体的な実例と留意点を示す。
抽象度順に並べると
「セキュリティ・バイ・デザイン」>「「セキュア・バイ・デザイン」」>「セキュアコーディング」
という感じか?
前半の感想
ある種の人にはとても難しい本だろうなという感想である。ある種の人とは具体的には、その、なんというか、エスアイアーみたいな名前の……。良いコード、良いデザインを追求する方法として自然にDDDを採用し、その上でセキュリティをどう扱うか、そういう文脈の本だと思っている。逆に言えば、良いコードを追求しないタイプの開発プロセスを採用していると本書で紹介されているようなプラクティスの導入は難しそうな印象。
あと、2章「ちょっと休憩: 『ハムレット』の悲劇」の原題は「Intermission: The anti-Hamlet」つまり反ハムレットの話なのだけれども、要はECサイトで「シェークスピアのハムレットの本」を「-1個」購入できるようになってしまうインシデントに関する話だ。これは、とても興味深い。