セキュリティ対策は「足す」より「減らす」 開発者と共有したい5つの設計原則：特集：ID・パスワードから始める「引き算」のセキュリティ（4）（2/2 ページ）

[田渕聖人，＠IT]

残す認証情報は「短く、狭く、自動で管理する」

　もちろん全ての認証情報をなくせるとは限らない。そこで、残すものは有効期間と権限を必要最小限にする。

　数カ月や数年間有効なAPIトークンや無期限のサービスアカウントキーは、漏えい時の悪用期間を長くするリスクがある。必要な場合でも、利用範囲を限定し、有効期間を短くすることが重要だ。

　徳丸氏は「現代のセキュリティ設計は『認証用のキーやトークンをそもそも極力使わない（持たない）ようにしよう』という方向へ議論が進んでいる」とし、「今後は認証情報の寿命を極限まで短くするか、使い捨てるというアプローチが主流になる」と提言している。

　例えば、「HashiCorp Vault」のようなシークレット管理ツールで必要なときだけ動的な一時認証情報を発行したり、OAuth 2.0などで短寿命のアクセストークンを利用したりする方法がある。

　ただし、短寿命であれば安全というわけではない。有効期間内に窃取されれば悪用される可能性があり、権限が過剰なら被害は大きくなる。短寿命化と最小権限をセットで設計することが重要だ。

　また、短寿命化を人手による鍵交換で実現しては意味がない。セキュリティ担当者は、認証情報の発行や更新を自動化し、開発者が個別に管理しなくても済む仕組みを用意する必要がある。

「シフトレフト」はチェック項目を増やすことではない

　これまで挙げてきた5原則を開発プロセスに落とし込む上で重要になるのが「シフトレフト」だ。

　「足し算」のセキュリティでは、リリース直前のペネトレーションテストやセキュリティチェックで問題を発見し、後から修正するという構図になりやすい。問題が見つかるほど手戻りは大きくなり、開発スケジュールとの衝突も起きやすい。

　第2回で西尾氏が強調したのは、「防御を有利に進めるには、攻撃が発生する前の段階にリソースを集中させるシフトレフトの考え方が重要」「本当に戦うべきは『左側』、すなわちソフトウェアの開発や管理、そして『特定・識別』というガバナンスの領域」という視点だ。

　ここでいうシフトレフトは、特定の製品や施策ではない。危険な設計を、できるだけ早い段階で見つけて修正するという考え方である。

　例えば、IDEやGit、CI/CDなど普段の開発ツールにシークレットスキャンやSAST（静的アプリケーション・セキュリティ・テスト）を組み込めば、ハードコードされた認証情報や脆弱（ぜいじゃく）なコードを早期に検出できるだろう。

　ただし検査項目を増やせばいいわけではない。全ての検出結果を一律にブロックすれば、誤検知やCIの遅延によって開発者が回避策を探す可能性もある。

　セキュリティ担当者が決めるべきなのは、何個の検査を導入するかではなく、どのリスクを重大と判断し、どの段階で止めるのか、何を警告にとどめるのかという基準である。開発者には、その基準に従って問題を早い段階で修正することが求められる。

「引き算」の対象は技術だけではない　運用ルールにもメスを入れる

　「引き算」の対象は、認証情報や検査だけではない。過去のさまざまな背景から残り続けるルールも見直す必要がある。

　徳丸氏が「診断結果で出てきた脆弱性を修正するかどうかというと、対応しない組織は対応しないための『言い訳』を一生懸命探している」「取りあえず脆弱性診断を受けること自体が目的になってしまっている」と指摘したように、セキュリティ対策そのものが目的化するケースは珍しくない。

　例えば「昔から決まっている」という理由だけで安全性の低い古いプロトコルを残していないか。チェックシートを満たすことだけを目的に診断を繰り返していないか。利便性を理由に、パスワードを復元可能な形で保持していないか。

　あるルールが何のリスクを抑えるために存在するのかを確認し、必要性が薄れていれば見直すことが重要だ。そのため、開発者から「なぜこのルールが必要なのか」と問われたとき、セキュリティ担当者も目的とリスクを説明できなければならない。必要に応じて、徳丸氏が紹介した「EBIOS」のようなリスク分析手法や、IPA（情報処理推進機構）などの公的ガイドライン、実際のインシデント事例を根拠にするといいだろう。

セキュリティ担当者は「安全な選択」を作る

　ここまでの議論で重要なのは、開発者とセキュリティ担当者の役割を「チェックする側」と「対応する側」に分けないことだ。

　セキュリティ担当者に求められるのは、開発者に注意や努力を求め続けることではない。安全な認証方式や標準アーキテクチャを用意し、開発者が迷わず選択できるようにすることだ。必要な検査をGitやCI/CDに組み込み、認証情報の発行や更新も自動化する。

　つまり、セキュリティ担当者が目指すべきなのは「開発者に安全な行動を求め続けること」ではない。安全な選択をする方が簡単な開発環境を作ることだ。

　西尾氏が提言した「防御側が圧倒的に有利な『左側』のフィールドに立ち返る」ことと、徳丸氏が示した古い設計やしがらみとの決別。その実践には、開発とセキュリティが同じシステムを見て、設計上のリスクと運用上の負担を減らしていくことが欠かせない。

　「引き算のセキュリティ」とは、持たなくてよい認証情報をなくし、必要なものだけを短く、狭くし、人手による管理や例外を減らすことだ。

　高額な製品を追加する前に、自分たちのコードやアーキテクチャ、開発プロセスに、まだ「持たなくてもよいもの」「管理しなくてもよいもの」が残っていないかを問い直す。その判断を開発者だけにも、セキュリティ担当者だけにも委ねない。

　開発とセキュリティが設計原則を共有し、安全な選択を標準にする。その積み重ねこそが、「ID・パスワードから始める『引き算』のセキュリティ」を現場に落とし込むための出発点になる。

特集：ID・パスワードから始める「引き算」のセキュリティ

---

セキュリティ業界では「サイバー攻撃の高度化・複雑化」という決まり文句がしばしば使われます。それ自体は間違っているわけではありませんが、企業を悩ませている真因は「攻撃の高度化・複雑化」ではなく「セキュリティ対策の高度化・複雑化」にあるのではないでしょうか。本特集では近年発生したランサムウェア攻撃の多くが認証情報の窃取から始まる状況を踏まえ、基礎中の基礎である認証情報（ID／パスワード）保護を基点にしたセキュリティ対策の見直しの重要性を提言し、そうした基本の対策さえ不十分になっている現状から抜け出すための指針を提供します。