Day 108 手法7：セキュア設計・チェックリスト Method 7: The Secure Design Checklist

サイバー判断力によるヒューマン・ハードニング

» 2026/02/13

[シリーズ構造] 柱D｜脅威の現実

セキュア設計チェックリストは、出荷前に使う"航空業界型"の軽量チェックリストです。判断を縛るのではなく、判断を守るための仕組み。設計段階で見落としを可視化し、セキュリティを「驚き」から「期待値」へ変えます。

▶ シリーズ概要：シリーズ全体マップ：人間のしなやかさ ― サイバー判断力のために

▶ 柱E｜脅威の現実 関連記事：

手法7：セキュア設計・チェックリスト

ここまで来たら、「敵対的に考える」はもう"手法"じゃない。マインドセットで、習慣で、（ガードレールがあれば）設計パターンにすらなる。

で、あと1つ必要になる。

出荷前に、見落としを拾う仕組み。

質問票じゃない。
官僚主義でもない。
チェックリスト、コンプラ用じゃなくて、航空業界で使われているチェックリスト（判断を奪わず、判断を守るためのチェックリスト）。

短くて使える。
鋭くて効く。

これは、コードを外に出す直前の「最終レンズチェック」だと思ってほしい。

全部チェックできたら「完了」じゃない - 気づけてるだけ。
チェックできない項目があったら失敗じゃない - 会話の起点になる。

このチェックリストは、セキュリティを
サプライズ → 期待値
に変える。

セキュア設計チェックリスト

1) 認証（Authentication）& 認可（Authorization）

エンドポイントは認証必須（意図して、明示的に公開する場合を除く）
認可は毎リクエストでサーバー側で強制（ログイン時だけじゃない）
セッション／トークンは予測可能な期限で失効する。ログアウトやパスワードリセットでアクセスが実際に止まる（「そのうち切れる」ではない）
JWTを使うなら：ログアウトを成立させるには、失効リスト（denylist）や短命トークン＋ローテーションなどの設計が必要
パスワードリセットで「そのアカウントが存在するか」を確定させない（ユーザー／メール列挙を起こさない）
ログイン／パスワードリセットにレート制限（そして異常は見える化）
MFA（多要素認証）は用意され、設計として推奨される（「上級者用の奥の設定」になってない）

2) 入力検証（Input Validation）

入力は許可リスト（allowlist）で検証（禁止リスト（denylist）頼みはしない）
SQLはパラメータ化（文字列連結はしない）
ファイルアップロードは制限する
- 拡張子の許可リスト
- サイズ上限
- 中身の検査（Content-Typeを信用しない）
- 必要に応じてマルウェアスキャン／サンドボックス
HTML出力はエンコードしてXSSを防ぐ（「フィルタ」だけを主防御にしない）
OSコマンド実行は極力避ける。避けられないなら：厳格にサニタイズし、隔離し、サンドボックス化する

3) データ保護（Data Protection）

機微データは転送中と保存時の両方で暗号化する
ハードコードされた資格情報はゼロ（例外なし
シークレットはVault／Secret Managerに置く（設定ファイル、ログに出るenv、仮コミットに置かない）
個人データは必要最小限だけ集める（設計で最小化）
データ削除は「削除」する。フラグを立てるだけではない。後回しでもない。
レプリカ、キャッシュ、保持期間（retention）の境界まで、削除の意味を詰める
GDPR相当の世界だと「消して」が本当に"消える"ことが要件になる

4) ログ & 監視（Logging & Monitoring）

セキュリティイベントをログに残す（認証失敗、アクセス制御失敗、権限変更、機微操作など）
ログに機微情報を入れない（パスワード、トークン、シークレット、不必要なPII）
ブルートフォースやログイン異常を監視する（記録だけで終わらせない）
アラートは「異常パターン」で発火する（"保存されてるだけ"にならない

5) APIセキュリティ

すべてのエンドポイントにレート制限（「地味なやつ」も例外にしない）
アクセス制御はエンドポイント単位で強制（できればロールだけでなくオブジェクト単位まで）
CORSは意図して設定する（デフォルト*にしない）
APIキーは定期ローテーションし、露出したら即撤回する
エラーメッセージでスタックトレースや内部情報を漏らさない（デバッグはあなたのためで、攻撃者のためじゃない）

チェックリストの使い方

年1回じゃない。
最後だけでもない。
「なんか怪しい...」のときだけでもない。

使う場所はここ：

アーキテクチャレビュー
高リスク機能のスプリント計画
大きな変更のコードレビュー
デプロイ前の承認
インシデント後の振り返り（再発防止を"構造"に落とす）

目的は完璧じゃない。
目的は 驚かないこと。

これが効く理由

チェックリストがやってくれるのは、記憶ができないこと。

圧がかかったときの後退（リグレッション）を防ぐ
文脈が変わっても、チームを同じ基準に揃える
セキュリティを「職人芸」から「再現可能な運用」にする

パイロットが大規模に飛べるのはこれ。
外科が回せるのはこれ。

実例として、WHOの手術安全チェックリストでは、重大合併症が11%→7%に減り、入院死亡率は1.5%→0.8%に下がった。

チェックリストが魔法だからじゃない。
正しい会話を、正しいタイミングで起こすから。

現場ではこう聞こえてくる

そのうち、こんな言葉が飛び交い始める：

「更新の認可チェック抜けてる -- マージ前に入れよう」
「待って、ここエラー出しすぎ。漏れてる」
「このAPIキー、Vaultに入ってない -- 先に直そう」
「パスリセ、ユーザー列挙になってない？」

この瞬間がサインだ。

チェックリストが"書類"じゃなくなって、文化の部品になってる。

敵対的思考が、構造として定着した証拠。

シフト

このチェックリストはゴールじゃない。

橋だ。

知ってる → やってる
意図 → 行動
設計 → 防御

そして、その橋の上で組織は反応型をやめて、レジリエントになる。

――――

[Series Structure] Pillar D | Threat Reality

The Secure Design Checklist is a lightweight, aviation-style checklist used before systems ship. It doesn't replace judgment or creativity -- it protects them. By surfacing blind spots early and consistently, security shifts from surprise to expectation, and from good intentions to reliable design.

▶ Series overview: Series Map - Human Flexibility for Cyber Judgment

▶ Other posts in Pillar E (Pillar D | Threat Reality):

Method 7: The Secure Design Checklist

By this point, adversarial thinking is no longer something you do.

It has become a habit.
A reflex.
And with the right guardrails part of the system itself.

But habits still have blind spots.

What we need next is not more training.
Not another policy.
Not a questionnaire that no one enjoys filling out.

We need a way to notice what we're about to miss before it ships.

That's where the checklist comes in.

Not the compliance kind.
The aviation kind.

Short enough to use.
Sharp enough to matter.

Think of it as the last quiet look before code leaves the runway.

If every box is checked, you're not "done."
You're simply aware.

If a box can't be checked, that's not failure.
That's where the conversation starts.

And that's the real shift:

Security moves from surprise to expectation.

How to Use the Checklist

Not once a year.
Not at the very end.
And not only when something feels wrong.

Use it while decisions are still cheap:

Architecture reviews
Sprint planning for high-risk features
Code reviews for meaningful changes
Pre-deployment approvals
Incident postmortems--so lessons turn into structure, not memory

The goal is not perfection.
The goal is not being surprised.

Why This Works

Because checklists do what humans cannot--especially under pressure.

They:

Prevent regression when things get busy
Keep teams aligned as context shifts
Turn security from heroic effort into repeatable practice

This is how pilots fly safely at scale.
This is how surgeons reduce avoidable failures.

Not because checklists are magic.
But because they force the right conversations at the right moment.

The Shift

This checklist is not the finish line.

It is the bridge between:

Knowing → Doing
Intent → Behavior
Design → Defense

And it's on that bridge that organizations stop reacting and start becoming resilient.

-----

References　参照・出典・参照文献

Haynes, A. B., Weiser, T. G., Berry, W. R., Lipsitz, S. R., Breizat, A.-H. S., Dellinger, E. P., Herbosa, T., Joseph, S., Kibatala, P. L., Lapitan, M. C. M., Merry, A. F., Moorthy, K., Reznick, R. K., Taylor, B., & Gawande, A. A. (2009). A surgical safety checklist to reduce morbidity and mortality in a global population. New England Journal of Medicine, 360(5), 491-499. https://doi.org/10.1056/NEJMsa0810119 (PubMed record: https://pubmed.ncbi.nlm.nih.gov/19144931/)

Information Commissioner's Office. (n.d.). Principle (c): Data minimisation. https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-protection-principles/a-guide-to-the-data-protection-principles/data-minimisation/

MITRE. (n.d.). CWE-78: Improper neutralization of special elements used in an OS command ("OS command injection"). https://cwe.mitre.org/data/definitions/78.html

National Institute of Standards and Technology. (2025). Digital identity guidelines: Authentication and authenticator management (NIST SP 800-63B-4). https://csrc.nist.gov/pubs/sp/800/63/b/4/final

OWASP. (n.d.). Authentication cheat sheet. https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html

OWASP. (n.d.). Cross site scripting prevention cheat sheet. https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html

OWASP. (n.d.). File upload cheat sheet. https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html

OWASP. (n.d.). Forgot password cheat sheet. https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html

OWASP. (n.d.). Input validation cheat sheet. https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html

OWASP. (n.d.). Logging cheat sheet. https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html

OWASP. (n.d.). OWASP API Security Top 10 - 2023. https://owasp.org/API-Security/editions/2023/en/0x11-t10/

OWASP. (n.d.). REST security cheat sheet. https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html

OWASP. (n.d.). Secrets management cheat sheet. https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html

OWASP. (n.d.). Session management cheat sheet. https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html

OWASP. (n.d.). SQL injection prevention cheat sheet. https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html

World Health Organization. (2010, December 11). Checklist helps reduce surgical complications, deaths. https://www.who.int/news/item/11-12-2010-checklist-helps-reduce-surgical-complications-deaths

European Union. (n.d.). Regulation (EU) 2016/679 (General Data Protection Regulation), Article 5: Principles relating to processing of personal data. https://gdpr-info.eu/art-5-gdpr/

European Union. (n.d.). Regulation (EU) 2016/679 (General Data Protection Regulation), Article 17: Right to erasure ("right to be forgotten"). https://gdpr-info.eu/art-17-gdpr/

蓮見祥子 2026/02/13 06:48:06 Comment(0)

前の投稿へ

コメントを投稿する

SpecialPR

検索