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

セキュリティ製品やルールを増やすほど、安全になるとは限らない。むしろ現場の負担が増え、基本的な対策まで形骸化することもある。では、何を減らし、何を残すべきなのか。開発者とセキュリティ担当者が共有すべき「5つの設計原則」を軸に、「引き算」のセキュリティを開発現場へ落とし込む方法を考える。

[田渕聖人，＠IT]

　認証情報（ID／パスワード）保護を基点にしたセキュリティ対策の見直しの重要性を問う本特集「ID・パスワードから始める「引き算」のセキュリティ〜ゼロトラスト狂騒曲の果てに」では、これまで3回にわたり、企業が陥りがちな「複雑化のわな」を浮き彫りにしてきた。

　初回は、相次ぐサイバー攻撃への対策として、新たなセキュリティ製品やルールを積み重ねた「足し算」が現場を複雑にし、担当者の負担を増やし、パッチ適用やアカウント整理といった基本的な対策まで形骸化させているという問題提起をした。

　第2回・第3回では有識者の知見を通じ、攻撃が発生する前の「左側」、すなわちガバナンスや開発の領域に防御の重心を置くこと、そして利便性や古い慣習を理由とした「形だけのセキュリティ」から脱却することの重要性を見てきた。

　ではここまでの議論を、実際のシステム開発やセキュリティ運用にどう落とし込めばいいのか。最終回となる本稿では、開発者とセキュリティ担当者が認証情報を中心としたセキュリティ設計について何を合意し、開発プロセスにどう組み込むべきかを考える。

　ここでいう「引き算」とは、セキュリティ製品を単純に減らすことではない。安全な状態を維持するために、人間が管理しなければならない認証情報や権限、例外、手作業を減らすことだ。目指すのは、開発者がセキュリティのために特別な努力をしなくても、安全な構成を自然に選択できる状態である。

セキュリティ担当者と開発者が合意すべき5つの設計原則

　過剰かつツギハギなセキュリティ対策は、開発現場に摩擦を生じさせる。新たな監視ツールやエンドポイントエージェントの導入では開発環境との互換性を確認し、本番環境へのアクセスやテスト環境の構築では複雑な例外申請や承認が必要になる。結果として、コードを書く以外の「手続き業務」が増えていく。

　東京大学の西尾素己氏が連載第2回で「導入すればするほど、担当者は『あれもこれも対応しなければならない』と、追い詰められた状態に陥る」と指摘した通り、対策の継ぎ足しはセキュリティと開発現場の負荷を押し上げる。

　問題は、負担が「面倒」で終わらないことだ。制約が多い環境では、開発者が業務を進めるためにルールを回避し、承認を得ていない外部サービスや個人アカウントを利用するといったシャドーITにつながる可能性もある。

　だからこそ、個別の製品やチェック項目より先に、セキュリティ担当者と開発者が設計原則を共有する必要がある。

　認証情報について、両者が合意したいのは次の5点だ。

1. ソースコードに認証情報を埋め込まない：APIキーやデータベース接続情報、OAuthクライアントシークレット、秘密鍵などをコードやリポジトリに残さない。
2. 可能な限り静的な認証情報を持たせない：長期間有効なアクセスキーを保持するのではなく、ワークロードIDやフェデレーションなど、資格情報そのものを減らせる方式を選ぶ。
3. 残す認証情報は最小権限・短寿命にする：必要な権限と有効期間を明確にし、漏えいしても攻撃者が利用できる範囲を限定する。
4. 発行・更新・失効を自動化する：人間が鍵を発行、交換、管理する作業を可能な限りなくす。
5. 例外には理由と期限を設ける：例外を恒久化せず、なぜ必要なのか、いつまで必要なのかを明確にする。

　この5原則は、開発者だけに課すルールではない。セキュリティ担当者から開発者への要求であると同時に、その要求を無理なく実践できる環境を用意するための基準でもある。

セキュリティ担当者からの要求は「コードに秘密を持たせない」

　最初に徹底したいのが、認証情報をソースコードやリポジトリに残さないことだ。

　APIキーやデータベース接続情報などが「開発環境だから」「ローカルでの動作確認だから」という理由でコードに書き込まれることがある。

　連載第3回でEGセキュアソリューションズの徳丸浩氏が語ったように「ソースコードそのものを保護する意味に比べて、その中に『認証情報』がハードコードされていることの危険性に対する重み付けや重大性の認識が、まだまだ希薄」なのが実情だ。ソースコードは、さまざまな理由で外部に漏えいする可能性がある。

　「プライベートリポジトリだから安全」「内部のテスト環境だから問題ない」と考えるべきではない。公開設定のミスや開発者端末からの情報流出、CI/CD（継続的インテグレーション／継続的デリバリー）環境の設定不備など、流出・露出する経路は複数存在する。

　つまりセキュリティ担当者からの要求は「気を付けてください」ではなく、「コードには秘密を持たせない」と明確にすることだ。

　その上で、開発者が安全な方法を選べる環境を標準として用意する。開発環境では環境変数などでコードから秘密を分離し、本番環境ではシークレット管理基盤から必要なタイミングで取得する方法がある。

　ただし、.envファイルなどに保存すれば、誤コミットや端末への残存といったリスクも残る。重要なのは、秘密情報をどこに置くかだけでなく、どのプロセスが取得し、誰が利用でき、いつまで有効なのかまで設計することだ。

　さらに、可能であれば静的な認証情報そのものをなくすのがいいだろう。

　例えば、「Amazon Web Services」（AWS）のIAMロール、Google Cloudの「Workload Identity」、Microsoft Azureの「Managed Identities」などを使えば、クラウドワークロードに長期間有効なアクセスキーを埋め込まずに権限を付与できる。CI/CDでもOpenID Connect（OIDC）フェデレーションを利用すれば、「GitHub Actions」などから長期間有効なAWSアクセスキーを保持せずに認証できる。

　セキュリティ担当者が求めるべきなのは、鍵を安全に保管することだけではない。そもそも鍵を持たなくても済む方式を選べるようにすることである。