シンプルだけど画期的、たった2行のRFC 9116の考え方を自社にも適用しませんか（1/2 ページ）

「モノづくりに携わる人」だからこそ、もう無関心ではいられない情報セキュリティ対策の話。でも堅苦しい内容はちょっと苦手……という方に向けて、今日から使えるセキュリティ雑学・ネタをお届け！今回は、2022年4月に正式公開されたばかりの「RFC 9116」についてフォーカスします。

公開 2022年08月24日 09時00分

更新 2023年12月18日 15時35分

著者

宮田健

[TechFactory]

印刷する連載新着通知を受け取る

　インターネット技術の標準化などを行うIETF（Internet Engineering Task Force）が発行している「RFC」をご存じでしょうか。RFCはさまざまな仕様やルールがまとめられており、皆さんがこの記事をWebブラウザで読むという行為の中にもたくさんのRFCが元になっており、実現できたものだと思います。

　その中で、少々興味深く、明日にでも対応が可能なRFCがあります。私がこれを知ったときは本当に画期的だと思いました。それは2022年4月に正式公開されたばかりの、RFC 9116です。

図1　RFC 9116: A File Format to Aid in Security Vulnerability Disclosure

　このRFCに沿った仕様で、この目的を達成するためには、Webサーバの特定の場所に、たった2行――「連絡先」と「失効日」だけを記載すればよいだけです。でも、これは本当に重要な情報で、画期的な仕組みだと個人的には思っていますし、この考え方を皆さんの組織、そして製品にもぜひ拡張してほしいと思っています。

RFC 9116とは「生きた連絡先」を明らかにするもの

　今回取り上げたRFC 9116は、Webサイトを運営する組織に対して、脆弱（ぜいじゃく）性を始めとする何らかのセキュリティ的な指摘をする際に、どこに連絡すればよいかというのを明らかにするものです。ファイル名は「security.txt」であり、このファイル名からもなんとなく想像が付くかもしれません。例えばGoogle（https://www.google.com/.well-known/security.txt）やFacebook（https://www.facebook.com/.well-known/security.txt）でも既に設置がされています。仕様自体は詳細に設定されているものの、上記の通り必須なのはたった2行のみです。連絡先と、その連絡先が“生きている”のかどうか。あえてExpiresを用意しているあたり、この仕様を考えた方々の苦悩を感じずにはいられません。

図2　「security.txt」のサンプル。必須なのは「Contact」と「Expires」のみ（RFC 9116より）

　たった一つのファイルではありますが、これがあるとないでは大きな違いがあると思います。日本における脆弱性のコーディネートを行うJPCERTコーディネーションセンターでも、「連絡不能開発者一覧」というページが用意されており、古いフリーソフトだけでなく商用のソフトウェアを含め、現時点で連絡が付かないソフトウェア開発者がたくさんいることが分かります。

図3　JPCERTコーディネーションセンター「連絡不能開発者一覧」

　ここに掲載されているということはソフトウェアに既に脆弱性が明らかになっており、修正が行われないままとなっているわけです。脆弱性への対応はソフトウェア自体をアップデートする以外、根本的な対策はありません。その意味では、この「連絡先が不明である」という状況は、利用者に取って大きな脅威となってしまいます。

　今回のRFC 9116に関しては、JPCERTコーディネーションセンターにおいても、「正しくつながる」ことの重要性をブログにて公開しています。ぜひ、こちらも参照してください。

A File Format to Aid in Security Vulnerability Disclosure - 正しくつながる第一歩 - JPCERT/CC Eyes | JPCERTコーディネーションセンター公式ブログ

次ページへ連絡先が必要なのはWebサイトだけではない