日々の破片

_ 徳丸浩とただただしのここだけの話 〜freeeのセキュリティって実際どうなん？〜

大崎のfreeeでfreee_kokobana。会議室＋机と椅子みたいな会場を予想していたら、広いスペースに作られた扇状劇場が会場でちょっと驚いた。（その後にオフィスツアーがあって、駄菓子屋やパブや図書室（は図書室かな）になっている会議室を見学してなかなかおもしろかった）

以下はメモ（敬称は略）

趣旨：Freeeのセキュリティのフリートーク

関係：徳丸とただの関係：徳丸はtDiaryのユーザだった。

ただとセキュリティテックとの関わり： 新卒入社すぐにヤンキードードゥルがきっかけ（ウイルスワクチンを開発）。そういえば、この話のウィルスワクチンを開発ということの実情とかを後で話すとか言っていたが省略されてしまった。

freeeのアーキテクチャ：もっぱらRails、最近は切り出してサービスはGo、（ここの2番目が聞き取れなかった）、フロントはReact。React＋Railsだとそもそも穴が開いていないことが多い。

一番力を入れてきたのは脆弱性診断をかっちりやる（リリースタイミングで確実に捕まえる）

やってみると、固い（Rails、React）ので滅多に出ない→何をすれば良いのか？

とはいうものの、事業規模の成長に合わせてM&Aで買ったプロダクトは割と出る。

ただからの質問：徳丸本を更新するとしたらどこを変えるか？

質問の意図：XSSなど、フレームワークの進化でほぼ出なくなった状況でどういうアプローチがあるか？

SQLインジェクション、CSRF、XSSは外せないが、ディレクトリトラバーサルなどは普通あり得ない

→　3時間で何をしゃべるか？　ファイルアップロードしたらどうなるか　レースコンディション

パスワードの保存

ReactであればOKか？ というとそうとも言えない。SPA＋SPA派生は徳丸本ではあまり意識していなかったので新しく書くのであれば必要と考える。

たとえばReactは固い、Railsは固い でもつなぐところは人間が作る

：パスワード変更で現在のパスワードを入れて通ったら変更する

パスワード変更のAPIはチェック、更新のAPIで更新 → 分離してはだめ

Freeeの今：

固定的な脆弱性は機械的なスキャンで見つかるし、静的解析もある

アーキテクチャの問題、API設計の問題は、まだ人間が見つける必要がある。

ただからの質問：どういう教育を徳丸さんの会社でやっているか？

合意：結局は、教育、自動化、人間の目

オブジェクトのIDを指定、IDを変えたら見える

APIは全部返す（見えてはならない情報まで含まれている）

要はビジネスルールのバグを見つける必要があるわけだが、ビジネスルールを使った検証というのは現状は無い

認証・認可周りを堅牢にする

・認証、認可をマイクロサービスに切り分けて全プロダクトが共通して利用

freeeでやりつつあること：権限のマトリクスを定義してテストする自動ツール

→ ビジネスロジックは汎用ツールがないので開発が必要だった。PSIRTは開発者でもあるのでOK

徳丸：権限マトリクスは作れ（たいていは無い）。freeeは素晴らしいですね。

→セキュリティの課題をエンジニアリングで解決

------

セキュリティチームだけではなく、他のチームもできなければならない

ただ： 取り組み自体はこの3年で充実： ほぼセキュリティ周りはPSIRTでやっている

開発チームがセキュリティのデザインドック（？ なんだか聞き取れなかった。知らない単語）

※（内山さんからこの部分を貰ったので引き写し）

- ほとんどのチームはdesgindocを書いている

- PSIRTはすべてのdesigndocをセキュリティ面からチェックしている

- これはとてもハード。会社が拡大する中スケールできないのでいずれ破綻する

- 本来は開発者がセキュリティについて判断できるようにしたい

- まずはセキュリティチャンピオン制度を始めた。PSIRTはそれをサポートしていく形にしていく

------------

仕様レベルのセキュリティ上の瑕疵をどう開発チームに判断させるか。

上流は難しい→ビジネスルール問題に行き着く

各開発チームにセキュリティチャンピオンを任命（立候補）してやらせる（PSIRTはサポートに回る）

教育

言いにくいところ： ここ数年で急激に成長したのでとりあえず仕事をアサインしてから、新卒がまとまって入るようになったのでちゃんと教育をカリキュラム化（体系化）が必要と考えている

自慢できるところ： 新卒向けに穴だらけのRailsアプリケーションを要塞化させる実習

とはいうもののコンテナ時代にあって、OSを生でさわるのは？

ハードニング（要塞化）のプラットフォームもコンテナ

演習用ではリソースの設定であふれるように仕込んでおく

インフラ側からの侵入可能な穴をあけておく

障害訓練（有名な）

→ 結局はお祭り

　見つかるのはチーム間のつながりの問題

過去に起こったインシデントを再度発生させて当時とは異なるメンバーにやらせる（レポートから連絡まで）

インシデント対応に新人が関われない（早い収束が必要なので経験者がアサインされる、当然）ので、再現で訓練させる

AIについて

徳丸： 各社ChatGPT使って云々 があるが、複数行のテキスト

ただ：

事業会社にはログがある

ログを機械学習に突っ込んで攻撃者の意図が掴めるのではないか？ 攻撃の文法が見えれば攻守の逆転（守備側が先回り）が可能ではないか？

ログの保管期間

時効は3年だが

残せるのであればすべて残す

内部で脆弱性を見つけた場合は、ログに攻撃の痕跡がないかを確認する

1ユーザからのリクエストが40xを多数占めていれば脆弱性を探していると判断できる

ユーザーサポートはおっかない。困ったお客さんはまずい情報を送って来る。どうすれば？ （ルール化）

企業の会計情報、社員情報 → レベルS

レベルCはpublic

レベルで基準を決める（DB切り分け、暗号化など）

MyNumberは独立したマイクロサービスで隔離

CertBotのクリティカルであっても問題があるコードを利用していなければトリアージュ

ゼロデイ攻撃は対応できないからゼロデイ攻撃。発生した場合にどうインシデント処理するかをあらかじめ決める（というか、障害訓練（お祭り）がそもそもそういうのだったような）

---

：攻撃側と守備側を逆転させるにはどうすればよいか？ というたださんの問題提起がおもしろい。

攻撃側のほうが知っているという状況をひっくり返し、守備側のほうが知っている状態を作れるのではないか。そのためにログをAIに食わせて攻撃のパターンマッチにより、察知できるのではないか。

※ ワクチンとウイルスの書き間違いを修正（かずひこさん、ありがとう）

体系的に学ぶ 安全なWebアプリケーションの作り方 第2版［固定版］　脆弱性が生まれる原理と対策の実践(徳丸 浩)