mike-neckのブログ

Java or Groovy or Swift or Golang

セキュア・バイ・デザイン 3章前半

読書メモ

読書メモ、対象がでかいし、ダラダラ読んでたのであまりまとまってない

全般的にいわゆる DDD 本(エリック・エヴァンスの本)のエッセンスが提示されている章。議論はそれなりに花が咲きそうだけど、結論はエヴァンス本読めになりそう。以下は個人的におっと思った部分のみピックアップしている

3.1.1 対象のドメインを簡素化したモデル

モデルは現実の簡素化です。 …ここで言うモデルとは、特定の表現方法のことではないのです。モデルとは、その対象となる現実の中で何が本質だと考えているのか…、ということを捉えた結果なのです。(p.80)

モデルと言うと何らかの図で何かを表現したものと考えていたが、そうではなく、現実から何かを捨て現在の課題にとって重要なものが何であるかを選別する行為であると読める。もしかしたら、ここは原文では modeling になっているかもしれないと思った。

3.1.2 モデルの厳格さ

ドメイン・モデルは豊富な情報を失う代わりに、厳格さ、ふるまいの明確さを得る。

システム開発において、そのシステムのユーザーとなる人に目を向けることは明らかに重要なことです。そして、そのシステムはユーザーとなる人が慣れ親しんだドメインを認識できるように…常に使っている言葉をシステムで使うように選択しなければなりません。(p.84)

ユビキタス言語の重要性

開発者にとって、結果としてすべきことはコードを書くことです。…コンピューターに対して受け取ったデータをもとに定義したルールに従って処理を行うように指示するものなのです。まさに、このことが、システム開発において厳格さが求められる理由なのです。

アプリケーションの開発者が行うのはコードを書くことなので、コンピューターを厳密に動かすためにモデルには厳格さが求められる。

厳格さは下記のように導かれる

  • ドメイン・エキスパートとの会話から導出
  • 開発者地震が今までの経験を元に推測する

3.1.3 深い理解を捉えたモデル

自転車に乗るロボットを作るのであれば、自転車に乗ることに関してほとんどのエキスパート…が有する知識よりも深い知識を持っていることが求められます。(p.88)

開発者がドメイン・エキスパートの頭の中を覗けたとしても、そこにはそのまますぐに使えるモデルが見つからない…ドメイン・エキスパートの中には真のモデルがないのです。…最高のドメイン・モデルを作り上げるためには、開発者とドメイン・エキスパートとの共同作業が必要不可欠であり、そのことを時間を掛けて何度も繰り返し行うことでモデルを進化させていきます。(p.89)

3.1.4 モデルの作成はモデルの選択を意味する

モデルを作成するには、多くの可能性のあるモデルの中から意思を持って選択していき、その中で、開発するシステムに対して要求されることにもっとも適したモデルを選択しなければなりません。つまり、モデルの目的を定義するのです。(p.90)

ここまでのまとめ

セキュア・バイ・デザイン 10章

読書メモ

クラウドによるセキュリティの原則を説明。その構成要素についても解説している。

クラウド的考え方によるメリット

  • クラウドの提供する可能性（機能）を余すとこなく活用できる設計
    • 12 Factor App
    • Cloud Native
    • 3 つの R(後述)
  • 12 Factor App + PaaSでの稼働(伸縮性 elasticity) = Cloud Native

10.2 環境に格納された構成情報

  • アプリケーション可能のための構成情報の管理がセキュリティ的にも重要だが、場合によって複雑になる
    • 構成情報をコードに持たせると危険
      • コードにアクセスできるすべての人がアクセスできてしまう
      • 複数の環境にデプロイする必要が発生すると構成情報ファイル化する
    • 構成情報をファイルに記述すると危険
      • 監査証跡なしにファイルを読める
      • ファイルにアクセスできる人がすべてアクセスできる
      • コードを外部の開発者と共有するときに危険性に気づく
    • デプロイ環境に構成情報を配置するとリスクを移転できる
      • デプロイ環境から構成情報を取得するように変更することで、構成情報とコードが分離される
      • (+)問題はアプリケーションからインフラに移動し、アクセス制御、監査証跡の取得が容易になる
      • (-)開発者からインフラ関係者に問題が移動しただけになるため、暗号化などのさらなる仕組みが必要になる
      • (-)復号化の仕組みを入れるためにアプリケーションに複雑さが混入する。解決は 3 つの R

10.3 stateless アプリケーション

  • インスタンス数でスケールアップするため、可用性向上
  • メモリリーク・サーバー乗っ取り等の障害で破棄できるので完全性向上(?)
  • 同、可用性向上

10.4 ログをファイルに残す危険性

  • 相反する性質
    • システムの悪用につながる機密性の高い情報
    • アクセスをよくしたい利活用できる情報
  • ログファイルの問題
    • 機密性が低い/漏出を防ぐ手段が乏しい/漏出後の追跡が難しい
    • だれも編集してないことの保証が難しく完全性に乏しい
    • インスタンス破棄、ディスク容量の制限などで可用性が低い
  • ログのサービス化
    • ログをサーバーのインフラに依存させない
    • ログのカテゴリ化、ユーザーの分類によりアクセスを制御、アクセス履歴により監査証跡も取得 = 機密性の担保
    • ログの書き込みは信頼できるリソース(アプリケーション)に限定 = 完全性の担保
    • サービスのスケールによりインフラのリソース問題を解消 = 可用性

10.5 システム管理プロセス

  • bad
  • good
    • システム管理プロセスのシステム化

これ、クラウド関係ないんじゃ…

10.6 サービス検出と負荷分散

  • サーバーインスタンスが定期的に生成・破棄されるので必須の技術

10.7 エンタープライズセキュリティの 3 つの R

  • Rotate
    • パスワード等のシークレットを定期的に変更する
  • Repave
  • Repair
    • ソフトウェアが更新可能になったらすぐに更新

      従来のセキュリティとの違い

  • 従来
    • 変化を防ぐアプローチ
  • クラウド
    • 変化を促すアプローチ

セキュア・バイ・デザイン 2 章

読書メモ

読書会に参加するので、まとめておくだけ

  • 2.1 ビジネスルールの観点における完全性の問題
    • 不正なデータ入力によって損失が発生してた
    • 不正なデータに対するサブシステムの振る舞いが異なっている
  • 2.2 浅いモデリング
    • 最初にモデリングできたと思ったあとに深く考えることをやめたその場しのぎのモデリング
    • 冊数、IDなどを Int 等の抽象的な型で表現できていることで満足(暗黙的に表現した概念)
    • 型がドメインでどのように機能するのかは理解できてない
  • 2.3 深いモデリング
    • 概念の表現ではなく概念の理解に向かう
      • 下限・上限、許される文字など
    • 専用の型を用いる
  • まとめ
    • モデルの不完全性から不具合=セキュリティ上の欠陥が生じる

2021 年も終わりの近況

ネタ

2021 年は何もできなかった。その多くはうつ病のためにやる気が無くなってたことが原因である。それは今も変わらない。

万年うつ病がひどくなったのは、仕事をさがしている間に何度か遭遇した突然連絡がとれなくなる企業のおかげである。

不採用にしたいんだが、企業が断ったことにしたくないのか、求職者から辞退の連絡を入れてもらえるようにダマを決め込んで急に連絡が取れなくなる。

このような企業のサービスは顧客の方を向いてなさそうで利用するのがこわいと思う。

今は、そんなうつ病機関中でもちょいちょい生存確認の連絡をくれた企業で働いている。

なお、契約の関係上個人事業主になっている。

読んだ本

全然読んでない。

最近になって少し心の余裕ができたので、次の本を読んだ。

今は次の本を読んでいる。初学者の人は増田さんの 『現場で役立つシステム設計の原則』 の次に読むと良いかもしれないが、用語として エリック・エヴァンス本 も読んでおいたほうがよい…のだが、そんなことしてたらいつまで経っても読み始められないので、読みたいと思った時に読むのが良いだろう。

体重

うつ病を生き残るのに大量に食ってたら太った。 83kg になってた。

プログラム

全然書いてない。

graalvm plugin の方も対応しなければ行けないのだが、うつ病でそれどころではない