It’s been almost a year since the EU’s executive announced it would propose rules for political ads transparency in response to concern about online microtargeting and big data techniques making mincemeat of democratic integrity and accountability. Today it’s come out with its proposal. But frankly it doesn’t look like the wait was worth it. The […]
モダンシステムにおける検証可能な設計について
この記事はプロダクション セキュリティ チーム、Ryan Hurst による Google Online Security Blog の記事 “Verifiable design in modern systems” を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
ソフトウェアの設計方法や構築方法は絶え間なく進化しています。現在、私たちは、セキュリティをソフトウェアに最初から組み込むものとして考えていますが、そのソフトウェアへの信頼を最小限に抑える新たな方法も模索し続けています。それを実現する方法の 1 つは、ソフトウェアが行ったことを暗号学的な確実性をもって確認できるようにソフトウェアを設計することです。
この投稿では、この暗号学的な確実性を実現する際に役立つ、検証可能なデータ構造という考え方を紹介します。検証可能なデータ構造の既存の応用例や新しい応用例についても説明します。また、皆さん独自のアプリケーションでこの構造を活用していただくためのリソースも提供します。
検証可能なデータ構造とは、暗号学的な確実性によって、そこに含まれているデータが正しいという合意を効率的に形成できるデータ構造です。
最も有名なのがマークル木です。マークル木が数十年にわたって使用されているのは、多くのレコードの中にデータの特定の部分が含まれていることを効率的に検証できるからです。そのため、ほとんどのブロックチェーンの基礎としても使われています。
このような検証可能なデータ構造は新しいものではありませんが、新しい世代のデベロッパーたちがこのデータ構造によって実現できる設計を発見することにより、採用が加速されています。
こういった検証可能なデータ構造を使えば、動作自体に検証可能性と透明性が組み込まれた要素を利用して、新たな種類のソフトウェアを構築できます。これは型強制に対する新たな形での防御になり、既存のエコシステムや新しいエコシステムにアカウンタビリティが導入されるとともに、規制機関、消費者、パートナーに対するコンプライアンスの実証も簡単になります。
証明書の透明性は、検証可能なデータ構造の大規模な利用例の 1 つであり、ブロックチェーンを利用せずに、インターネットの中核インフラストラクチャを保護する方法です。私たちはこのパターンを使い、ウェブを破壊することなく、あらゆる人が利用する既存システムに透明性とアカウンタビリティを導入することができました。
残念なことに、検証可能なデータ構造とそれに関連するパターンの機能はあるものの、デベロッパーがスケーラブルな実稼働品質のシステムを設計、開発、デプロイするうえで利用できるリソースは多くありません。
このギャップに対処するため、Google が証明書の透明性の構築に使ったプラットフォームを汎用化し、他の種類の問題にも応用できるようにしました。このインフラストラクチャは、何年にもわたってこのエコシステムの一部として使われているので、よく理解されており、実稼働システムに安心してデプロイできます。
そのため、このプラットフォームは、医療、金融サービス、サプライ チェーンなどの領域のソリューションで活用されています。さらにこのパターンを応用し、Google のプロダクトやサービスの他の問題にも、透明性とアカウンタビリティの特性を適用しています。
その実現に向けて、2019 年にこのプラットフォームを使い、Go Checksum Database によって Go 言語のエコシステムにサプライ チェーンの整合性を導入しました。このシステムにより、デベロッパーは、Go のエコシステムをサポートするパッケージ管理システムが、意図的、恣意的、偶発的に誤ったコードを公開しても、それが見逃されることはないという確証を得ることができます。Go ビルドの再現性によって、ソース リポジトリにあるものがパッケージ管理システムにあるものと一致するという保証を得られるので、これは特に有力です。このソリューションは、ソース リポジトリからコンパイルされた最終アーティファクトまで、一貫して検証可能なチェーンを提供します。
このパターンのもう 1 つの活用例が、最近発表された Sigstore という Linux Foundation とのパートナーシップです。このプロジェクトは、オープンソース エコシステムへのサプライ チェーン攻撃が増え続けていることへの対応です。
サプライ チェーン攻撃が成立するのは、チェーンのリンク部分に弱点があるからです。ビルドシステム、ソースコード管理ツール、アーティファクト リポジトリなどのコンポーネントは、すべて重要な実稼働環境なので、それ相応に扱う必要があります。そのためには、まず、チェーン全体の出所を検証できるようにする必要があり、Sigstore の目的はこれを実現することです。
現在、私たちは、このパターンとツールを使って、デバイスのファームウェアで、ハードウェアによって強制されるサプライ チェーンの整合性を実現する作業をしています。これにより、ファームウェアのサプライ チェーンに透明性とアカウンタビリティが導入されるので、私たちが日々利用するスマートフォンなどのデバイスに対するサプライ チェーン攻撃が減るものと期待しています。
以上のすべての例で、検証可能なデータ構造を使い、サプライ チェーンでアーティファクトの整合性を保証しています。これにより、顧客、監査者、内部セキュリティ チームは、サプライ チェーンのすべての関係者がそれぞれの責任を果たしていることを確信できます。これは、サプライ チェーンの利用者の信頼を得るうえで役立ち、発覚する可能性が増えるため内部関係者による立場の悪用を阻止できます。また、アカウンタビリティが導入され、関連システムが継続的にコンプライアンス義務を果たせるようになります。
このパターンを使う場合、最も重要なタスクは、どのデータを記録するかを定義することです。そこで、分類とモデリングのフレームワークを作成しました。これは、以上で説明したシステムに検証可能性を組み込む際の設計に役立ちました。ご活用いただければ幸いです。
検証可能なデータ構造の詳細については、transparency.dev ウェブサイトや、皆さん独自のアプリケーションで使っていただけるようにまとめたツールやガイダンスをご覧ください。