セキュア・バイ・デザイン 第10章 クラウド的考え方によるメリット
===
###### tags: `セキュア・バイ・デザイン読書会`

# Discord開始位置

-

# 自己紹介

- なかじま（J.Nakajima）
- ファシリ役
- タイムキーパー役
- こばやし（t2_Kobayashi）
- 読み上げ役

# 参加の仕方

- マイクはいつでもONにして、話に参加して結構です。
- テキストチャットでも、コメントやリアクションでどんどん参加してください！ラジオ担当が拾っていきます。
- 聞いているだけの方もOKです！

# ディスカッションをより豊かにするためのグランドルール

- 参加者は毎回任意
- 今回は不参加、次回は参加をするといった気軽な感じ
- 途中参加も断然OK! まずは聞くだけでも大丈夫です！
- フィードバックを恐れない
- マサカリは怖いと思いますが、アウトプットからのフィードバックを受け、学びを深めていきましょう
- アウトプット7割：インプット3割の気持ちで臨みましょう！
- 経験の有る無しは気にしない
- 自分はDDD非経験者だから……と気後れする必要はないです
- 堂々と意見や疑問を語りましょう
- ページ数と同時に、節のタイトルやキーワードを言って頂けるとスムーズです
- 電子書籍で読んでいるとページ数ではわからないため
- 話していない人が、率先してメモしましょう
- このHackMDはみんなのものです。どんどん書いていきましょう:+1: :+1:
- 気になる質問や同感するものには :+1: を末尾につけてください。

# タイムテーブル

| 時間 | 所要時間 | 内容 |備考 |
| -------- | -------- | -------- | -------- |
| 19:50- | - | 集合開始 | |
| 20:00-20:15 | 15分 | 当日の流れとグランドルールの共有 | |
| 20:15-20:25 | 10分 | 感想記入&HackMDに書かれた皆さんの感想・気づき・疑問をもっと掘り下げたいものを、 :+1: 付けていく | |
| 20:25-21:55 | 90分 | 本の節ごとにディスカッション（ここでも適宜、HackMDに気づきとか書いていってもらっていいです） | |
|21:55-22:00 | 5分 | 次回開催日と読む範囲決めてクローズ | |

## 下に感想などを書いていって下さい。どんな些細なことでもOKです。

---

# 第10章 序章
## 目安の時間
- 22分

## 感想・気づき

- > p.369 本書が対象としているのは、クラウド・アプリケーションの開発から生まれたセキュリティを向上させるのに使える設計のコンセプトなのです。
- かなり目的を絞ってるので、これを念頭に置いて読んでいく

- > p.370 エンタープライズ・セキュリティの3つの「R」とは、定期的に変えること（Rotate）、作り直すこと（Repave）、修復すること（Repair）を表す3つの英単語の頭文字で、安全なシステムを構築するための手法のことです。
- これ知らなかったな :+1:

## 疑問

---

# 10.1 Twelve-Factor Appとクラウド・ネイティブの2つのコンセプト
## 目安の時間
- 22分

## 感想・気づき

- Twelve-Factor App
- https://12factor.net/ja/
- 7.ポートバインディングと12.管理プロセスは、どうしてそうするのかの理由がわかってないな

- > p.371 さらに、これらの要素のいくつかはセキュリティの観点においても興味深いものがあり、それらをシステムに正しく導入することで、安全性を高められると本書では考えています（これらの要素は安全性を高めるという理由でTwelve-Factor Appに入れられたわけではないのですが）
- あくまでTwelve-Factor AppはSaaSを作り上げるための方法論が主題

## 疑問

---

# 10.2 環境に格納された構成情報（configuration）
## 目安の時間
- 22分

## 感想・気づき

- > p.373 しかしながら、セキュリティの観点から見ると、プログラムのコードとアプリケーションの構成情報は、そのアプリケーションをオンプレミスで稼働するのかどうかに関係なく、必ず分けるべきです
- セキュリティ観点で考えてたわけではないけど、これはめっちゃわかる。:+1:
- この引用文の後にすぐ出てくる、鍵の更新を自動化したりといった運用がやりやすくなるから、分けていた
- GitHub に認証情報とかを置きたくなくて自然とこういう形にせざるを得なくなった記憶がある :+1:

- リスト10.1の例は、ドメインの関心事の違いな気がしてきた
- プログラムの視点においては、クレデンシャルもポート番号やタイムアウト値と同じ「構成情報」という見方となり、セキュリティの視点から見ると、クレデンシャルは外部に漏らしてはいけない情報という見方に変わるので、コード上に記述してしまうのはNG:+1:
- > p.377 デプロイする環境から取得する、というものです
- そのデプロイする環境に入ることができてしまったら、抜き取ることができてしまうと思うなと思った:+1:
- ただ、その環境に入れる人たちを限定すれば、開発者はそれを意識しなくて済むから問題ないのか

## 疑問

---

# 10.3 状態を持たない（stateless）独立したプロセスとしてのアプリケーションの稼働
## 目安の時間
- 22分

## 感想・気づき

- p.380のコラムにある最小権限の原則は、普段の設計にも通じるところ
- クラス設計の場合は、ふるまいに対して必要最低限のデータを持たせること
- > p.383 システム・ユーザがルート権限を持つプロセスでアプリケーションを稼働し、そのアプリケーションでクライアントからのリクエストを受け付けるようにしていることがあります。このとき、もし、悪意ある第三者がこのプロセスを乗っ取った場合、ルート権限を使って壊滅的な被害を与えられるようになります
- なんでもできるからroot権限のままにしていることは確かにあったけど、こう考えるとまずい:+1::+1::+1::+1:

## 疑問

- なんでDBやメッセージキューなどをバックエンド・サービスとこの本では呼称しているのか
- バックエンドという名が着くと、業務ロジックのあるAPIも含まれそうなイメージ
- この呼び方は一般的？
- https://12factor.net/ja/backing-services 参照。あまり一般的な用語ではないような気はします。
- かなり昔から、ある程度は耳にしたことはあるし、自分も使うこともあります。
- サーバサイドのフロントエンドサービスとバックエンドサービス、みたいに
- バックエンドサービスから見て、更にバックエンドもありえます

---

# 10.4 ログをファイルに残すことの危険性
## 目安の時間
- 22分

## 感想・気づき

## 疑問

---

# ================= 8/6はここから =====================

# 10.5 システム管理（administration）プロセス
## 目安の時間
- 30分

## 感想・気づき

- > p.392 残念なことに、システム開発において、システム管理に関する機能は忘れられたり、軽視されたりしがちです。
- [Discord](https://discord.com/channels/432531367427964929/911610565103845387/1005441942408138853)
- これは自分でも経験があるな。いまはSQLで直接DBをいじって運用をして、必要になったときに自動化をするとか
- これを軽視しないようにする対策とかって何かないかな
- 社内向けにも、社外向けのフロントエンドと同じフレームワークを使って同じレベルのサービスを提供するような形にすべきだなーというのは幻視してます（実践したことはない）
- こういうシステム管理・システム運用機能は、ある程度の運用業務プロセスまで見通せてないと疎かにされがち。でも、運用業務設計は軽視されて、後に回されたり、そのまま放置されたりすることの方が多い。
- 軽視というかそもそもどう設計したら良いのかわからんっていう方も多い節はありそう。（開発と運用が分断されていて、開発ばかりやっているエンジニアとか）:+1:
- 運用業務設計がきてないと、運用負担や特殊対応時のリスクが爆上がりで、「運用でカバー」という名の下に、ひどい尻拭いをさせられる人たちが出てくるのでつらい。:+1::+1:
- 後付けで改修とがむずかしいものもあるので、本来なら、運用を踏まえて、そも要求の一部として扱い、齟齬がないように基本設計の段階で考慮しておくべき。運用責任者がOK出せないようなものを作り始めるのもリスキー。:+1:
- OK出てたけどいざ動かしてみるとやっぱこれじゃダメパターンがあるので、やはり管理系もセットで作って常に確認できるようにしないといけない（戒め）
- 緩やかにでも最初に決めておくべきことと、後から必要に応じて対応すれば良いものは峻別して、少なくとも前者は疎かにしないようにしたい。
- と、次期システムの本番移行準備段階に入ってから、運用の相談を持ちかけられて、運用設計を一から見直しだね♪となってる某システムを横目に見ながら。あれだけ前から言っておいてあげたのに……。
- 開発も運用も同じチームがやれば、運用設計はこうしなきゃって知見は溜まっていくと思うけど、やっぱり分離したいのかな

- > p.393 外部の攻撃者によるリスクだけでなく、システム管理者が間違った操作をしてしまうことで問題を起こすリスクも抱えることになります。:+1:
- [Discord](https://discord.com/channels/432531367427964929/911610565103845387/1005438699288395816)
- 確かに、操作の自由度が高いと何度も確認挟んだりして辛いかも。出来る行動が制限されてる方が後々楽と考えるようにすれば、この辺りは比較的取り組みやすいのかな
- sshで入って手で運用すること自体に慣れきってしまって、あまり疑問に思わなかったりするよなーとなるから、早めにこういう芽は摘み取っておきたい

> p.395: そして、もう 1 つ注意しないといけないことは、仮に、システム管理機能がデプロイされる システムの一部に含まれていたとしても、この機能は他の通常の機能とは別のプロセスで稼働 させなくてはならない、ということです

- プロセスとして分離するだけでなく、サーバホストをマルチホームドにして、ネットワークも分離させておくとかも併せて行なわれることが多い (と思う)。ネットワークインタフェースが分離されていることでトラヒックが分けられるので、通信遮断をしたり、高トラヒックで通信が滞ってもメンテナンスアクセスできるようにするため。
- [マルチホーム](https://e-words.jp/w/%E3%83%9E%E3%83%AB%E3%83%81%E3%83%9B%E3%83%BC%E3%83%9F%E3%83%B3%E3%82%B0.html)知らなかったので、ぐぐった:+1:

## 疑問

- > p.393 アプリケーション・コードとシステム管理に関するスクリプトを異なるチームが担当している場合、チーム間の関係が緊張してしまい、外交的になってしまう、というものです
- [Discord](https://discord.com/channels/432531367427964929/911610565103845387/1005437549495459921)
- このへんのニュアンスがわからなかった。オープンなコミュニケーションができずに、お互いの腹を探るみたいな感じだろうか :+1::+1:

---

# 10.6 サービス検出（service discovery）と負荷分散（load balance）
## 目安の時間
- 30分

## 感想・気づき

- P.398 クライアントサイドでの負荷分散とは言っているが、サービス検出サービスを介在するのでいまいちクライアントサイド感がない気がしている
- [Discord](https://discord.com/channels/432531367427964929/911610565103845387/1005448216705241131)
- これは、分散先を決定するのが、LBなど一元管理している側か、クライアント側かという観点ですね。:+1:
- アドレスが動的に変化しないシステム構成であれば、クライアント側だけで対象の死活監視もして振り分け先をコントロールできるので、よりシンプルにはなる。

## 疑問

- p.398のクライアント・サイドでの負荷分散が選択される理由の1つに「アーキテクチャとデプロイの手続きをシンプルに保てる」とあるけど、果たして本当にそうなんだろうか？:+1::+1:
- [Discord](https://discord.com/channels/432531367427964929/911610565103845387/1005445516726915092)
- ハードウェアの方だとロードバランサーの設定とかがあるかもしれないけど、クライアントサイドでの負荷分散はサービス検出とそれに基づいてどこのサービスに投げるかのロジックが一定あるので、複雑化しやすそうなイメージがある :+1:

---

# 10.7 エンタープライズ・セキュリティの3つの「R」
## 目安の時間
- 30分

## 感想・気づき

- 持続的標的型攻撃
- https://www.lac.co.jp/lacwatch/report/20150728_002565.html
- シークレット情報を環境変数から取るとしたら、Repaveもセットでやる感じなのかなとは思った（大体アプリケーションが立ち上がった時に環境変数を読み込むと思うので）
- [Discord](https://discord.com/channels/432531367427964929/911610565103845387/1005457527183519784)
- ついでに Repair もするよな～と思っていたら P.406 の NOTE に『修復（Repair）を一種の作り直し（Repave）として考えましょう。』と書いてあった
- > p.406 もしアプリケーションをクラウド環境で稼働していないのにもかかわらず、この修復を行おうとしているのであれば、少なくとも仮想サーバが必要になります。
- [Discord](https://discord.com/channels/432531367427964929/911610565103845387/1005457967405088848)
- 言い方的には、やはりここはクラウドメインで、まあ他の環境でも出来なくはないけど、という感じの話なのか
- 昨今は、ある程度の規模ならば、オンプレでも仮想化基盤を利用して VM ないしコンテナで運用していることも多くなっていそうではある。

## 疑問

- Rotate をクラウドサービスを使わずにやるとしたらどんな手法がメインになるのだろう？:+1::+1:
- [Discord](https://discord.com/channels/432531367427964929/911610565103845387/1005453202684137472)
- > P.401 パスワードなどのシークレットは数分ごともしくは数時間ごとに変えるようにしましょう。
- [Discord](https://discord.com/channels/432531367427964929/911610565103845387/1005452438976876574)
- 例えば、DBのパスワードを変えるとして、具体的にどのようにするのでしょう？:+1::+1:
- AWSとかGCPのシークレットマネージャ的なもので管理させるのはわかるけど、自動的に変更するような設定あるんだっけ（あまりそこらへんの機能詳しくない）
- AWSだと、勝手にDBパスワードローテートしてくれる機能ありますね。　
- AWS Secrets Manager とは? https://docs.aws.amazon.com/ja_jp/secretsmanager/latest/userguide/intro.html
- Repave と Repair はセットのように思えるが、これは現在は実質的にセットになっているだけで、3Rが出た当初は Repair だけやるパターンが一般的だったのだろうか？（コンテナが一般化する前とかだと仮想環境まるごと作り直しは重そうだし）:+1:
- [Disord](https://discord.com/channels/432531367427964929/911610565103845387/1005455193300803627)

- Repaveの手段としてさくっとできそうなの何があるだろうか:+1:
- [Discord](https://discord.com/channels/432531367427964929/911610565103845387/1005456074238865418)
- replicasを指定することはできるけど、数時間おきにローリングデプロイし直すって設定がパト思いつかなかった
- k8sだとkubectl roring restart コマンドを定期的に投げるようなスクリプトは組めそうだけど、うーんって感じ

- > P.407 加えて、使用しているサード・パーティー製のソフトウェアに対する新しいセキュリティ・パッチが入手可能になったら、そのパッチを対象のアプリケーションに適用することも忘れないようにしてください。
- [Discord](https://discord.com/channels/432531367427964929/911610565103845387/1005448624878141563)
- サード・パーティー製のライブラリを活用されている会社が殆どだと思いますが、皆さんの会社ではどんな雰囲気のアップデート戦略を取っているのか（セキュリティに問題でない範囲で）聞いてみたい。:+1::+1::+1::+1:
- 言語やライブラリのバージョンは、開発するタイミングで上げる
- ナイトリービルドで更新版パッチを当てたものをテスト、って理想を掲げますが、結局リリースビビってやらなかったりします。ここら辺は重大な問題重ねて、全体の優先度意識を上げてくのかなと思ってます。
- Dependabot とかを使って通知が来たらすぐ CI/CD 通して出す

---