Issue #3: Private Network Access の概説 + Sigstore による Artifact 署名の実践例 + ほか

具体的な挙動変更が Chrome 98 から起こる Private Network Access (PNA) の動向、Sigstore によるコンテナ/アーティファクトへの署名の実践例、その他プロダクトセキュリティ各方面に関して米内が気になった動向をお伝えします。

Takashi Yoneuchi

Written by Takashi Yoneuchi

Published at January 23, 2022


Share this article with:


こんにちは、もっと楽にセキュアなプロダクト開発/運用を実現できるようにしたい米内(@lmt_swallow)です。今週は影響範囲もそこそこ広そうな Private Network Access という仕様に関してやや重めに紹介します。最近そういうチャネルを意図してウォッチしているからというのはありますが、今週は Sigstore プロジェクトの用例をやたら見かける一週間だったので、今週も Issue #2 に引き続きソフトウェアサプライチェーンに関する話題をやや重めに扱っていきます。

📶 Tech

⚒️ Application Security

👀
プロダクトコードのセキュリティを保っていくためのツールや、セキュリティフレームワークに関する情報を整理するセクションです

“Private Network Access: introducing preflights” from Google Chrome Team

Chrome 98 から段階的に Private Network Access という仕様に関する Chrome の挙動変更が行われるとのことです:

Private Network Access: introducing preflights - Chrome Developers

Private Network Access は、ラフに表現するなら「”プライベート” なネットワーク内のホストへのリクエストやローカルホストへのリクエストを、より ”パブリック” なネットワーク上にある Web サイトから行う際に、リクエストを受け取る側に CORS の Preflight Request の処理を要求する」という仕様です。このような仕様を導入するモチベーションは、プライベートなネットワーク内への Web ブラウザを起点とした攻撃(例: CSRF 攻撃)の可能性を低減することにあります。

より具体的に述べるなら、Private Network Access 以後の世界においては、「自端末の上流にいるルーターの Web コンソール」のような ”プライベート” な対象に対して “パブリック” なネットワークに属する http://example.com からリクエスト R を送ろうとする際に、まず以下のような Access-Control-Request-Private-Network を伴う CORS プリフライトリクエストが送出されます:

OPTIONS /test HTTP/1.1
Host: router.local

これに対し、そのプリフライトリクエストを受け取ったホストが、以下のような Access-Control-Allow-Private-Network を伴う適切なレスポンスを返却したときのみ先述のリクエスト R が送出されるようになります。それ以外の場合はリクエスト R は送出されず、当該リクエストは失敗に終わります。

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://example.com

目下 Chrome 98 から始まる変更は、具体的な通信のブロックまでは行わず、Developer Tools 上での警告を行うだけの変更に留まる見込みとのことです。

▫️
これは余談ですが、何を以てある HTTP 通信が “プライベート” であると判断するべきかは実はあまり自明なことではありません。
▫️
たとえば、Fetch Standard や HTML Standard 等、現代の Web を支える各種 Standard は IP アドレスに関する情報(DNS レイヤと深く関わるような情報) をあまり取り扱っていません。とりわけ Web ブラウザの多くの機能が Web リソース間の隔離を図る上で拠り所としている Origin (HTML Standard) は、具体的にどのような IP アドレスとの通信を行うかを情報として持たないものですから、上述のような制限や Origin という概念をもとにして構成できるものではない(はず)です。
▫️
そこで本仕様は、RFC 1918 で定義される IPv4 アドレス空間のカテゴライズを拡張した IP address spaceという概念を新たに導入しています。具体的には IPv4/IPv6 のアドレス空間を local, private, そして public の 3 つに分割します。
▫️
その上で本仕様は、less public な IP 間で発生するリクエストを Private Network Request と呼称し、これをもとに Fetch (やそれに連関するいくつかの Standard) に変更を加えます。とりわけ現在は以下のように定義されている、Private Network Request の発行に際して Secure Context と CORS プリフライトリクエストの成功を要求する、というのが大きな変更です:
”This document proposes a few changes to Fetch, with the following implication: private network requests are only allowed if their client is a secure context and a CORS-preflight request to the target origin is successful.”
▫️
現状 GitHub 上の Issue でも数々の議論が行われていますが、感覚的には、この手の仕様の導入や実装においては種々のコーナーケースが見つかりそうです。もしかするとバグハンター的にも面白い仕様なのかもしれませんね。

なお本仕様は、以前 CORS-RFC1918 と呼ばれていたもので、現在は WICG が以下のリポジトリにおいて管理されています:

GitHub - WICG/private-network-access

Chrome Platform Status

☁️ Platform Security

👀
プロダクト(とりわけ一般的な Web プロダクト)のインフラストラクチャ/プラットフォームのセキュリティを保っていくための情報を整理するセクションです

Amazon GuardDuty Now Detects EC2 Instance Credentials Used From Another AWS Account

GuardDuty に便利機能が出ていますね (この手の地味な検知ありがたい):

Amazon GuardDuty now detects EC2 instance credentials used from another AWS account

AWS Trusted Advisor Now Integrates with AWS Security Hub

こちらも Security Hub ユーザーにとっては便利な話です:

AWS Trusted Advisor now integrates with AWS Security Hub

🛣️ Supply Chain Security

👀
プロダクト開発のサプライチェーンのセキュリティに関する情報を整理するセクションです

The OpenSSF Launched Scorecard v4

オープンソースエコシステムのセキュリティに取り組む Open Source Security Foundation (OpenSSF) が、サプライチェーンセキュリティへの取り組み状況の可視化や具体的な問題の検出/対応を支えるためのツール Scorecard v4 をリリースしました:

Reducing Security Risks in Open Source Software at Scale: Scorecards Launches V4 - Open Source Security Foundation

Reducing Security Risks in Open Source Software at Scale: Scorecards Launches V4

UX 面やカスタマイズ性の面で改善の余地はあるなと思うものの(そういう文脈もあって最近ポリシーエンジンについて思いを巡らせたりしているのですが)、ソフトウェアサプライチェーン文脈のプレイヤーはガンガン OSS コミュニティに貢献していていいですね。

Thread Model and Best Practices for Kubernetes Admission Controllers

Kubernetes の Admission Controller を作る人や管理する人向けに、Admission Controller の脅威モデルや、その設計/実装時に具体的に気をつけるべき項目のリストが kubernetes.io にポストされています:

Securing Admission Controllers

The Trend of Real-World Adoption of Container/Artifact Signing Continues

今週はよく Sigstore/SLSA/in-toto 方面と関連した、具体事例の話が Twitter のタイムラインに流れてきていた気がします。例えば AWS Karpenter が Sigstore の諸ツールを用いた署名付きコンテナをリリースするようになったり:

Kubernetes が v1.23.2 (かそのちょっと前)のリリースから SLSA v0.2 Predicate のついた in-toto attestation をリリースに添えるようになったり:

Wasm で Admission Control のためのポリシーを書けるようにしてくれるプロジェクト Kubewarden が、Sigstore ツールチェインによりポリシーにアタッチされた署名を検証できるようになっていたり(これは昨年末の話ですが):

feat: Sigstore verification of policies on download by viccuad · Pull Request #135 · kubewarden/policy-server

apt.llvm.org がリリース時のソースコード配布の際に Sigstore ツールチェインによる署名を付与するようになっていたり、というようにです:

Recent improvements on apt.llvm.org

筆者は Sigstore ツールチェインの利活用がこの水準で進むのはもう少し先だろうと踏んでいましたが、近年のソフトウェアサプライチェーンに関する種々のインシデントが、思ったよりもこの領域の世界的な流れを加速させているようにも思います。元来 SCA 製品が SBoM の生成管理や、その脆弱性 DB の突合管理をするというのが関の山だった時代が続いていたように思いますが、そこから現在は (1) ソフトウェアサプライチェーンの根っこの方にいる大きなプレイヤーから順に SBoM / Software Provenance を適切に生成・管理しはじめるフェーズであり、かつ (2) 末端のプレイヤーが SBoM / Software Provenance の生成・管理を容易に行えるようにするためのプロジェクト(例: Tekton Chains)の検証フェーズに明確にシフトした感じがあるというか。

さらに抽象的なことを言うなら、一昨年くらいからワークロードのアイデンティティ管理の方面に強く感じてきた SRE 的テクノロジとセキュリティ系テクノロジの融合の流れの中が、ソフトウェアサプライチェーン領域においても感じられるようになったな、という気持ちがあります。面白くなってきましたね。

⚙️ Security(-Aware) Components for Products

👀
プロダクトのコンポーネントとして使えるようなセキュリティプロダクト(例: 認証認可に関するコンポーネントを提供する Auth0)についての情報を整理するセクションです

“OPA Guidebook” by Anders Eknert

Styra の Anders Eknert さんが OPA に関するガイドブックをリリースしていました:

Introduction

ざっと見た感じよさそうですが、日本語だと @m_mizutani さんの『OPA/Rego 入門』というのもあるので、日本語ネイティブの方はこちらも参考にされるとよさそうです:

OPA/Rego入門

“Build you a Google Groups”, a Tutorial to Design Permission Management like Google Groups with Authzed

Google Groups 的なパーミッション管理を Issue #1 で紹介した Authzed を利用して実現するチュートリアル的記事が Authzed から出ています:

Build you a Google Groups

Authzed、ドキュメントを見る限りはどんどん体験がよくなっていそうでいいですね。筆者は彼らのコアエンジンである SpiceDB を宅内サービスのために利用してみているのですが、(まだ実用上の課題は残ると感じるものの)いい感じに更新が入っていて結構いい感じなので、引き続き応援していきたいところです 🙏

👥 Security-Aware Team/Culture Building

👀
セキュリティに関する高い意識を持ったチームを作る・カルチャーを作る取り組みに関する情報を整理するセクションです

[中の人] セキュアな Web 開発のための e-learning「KENRO」がウォンテッドリー株式会社/株式会社インフォキュリオンでの利用事例を公開

筆者(米内)の所属している株式会社 Flatt Security では、セキュアな Web 開発をテキストで学び・実際に Web アプリケーションを攻撃して学び・脆弱なソースコードを実際に修正してみて学ぶための e-learning サービス「KENRO」を提供しています。今週はこの KENRO の活用事例を新しく 2 つ公開しました:

アーキテクチャが複雑化しているからこそ、Webセキュリティの基礎を学ぶ必要があった。Railsへの理解も深まったと評価 | KENRO

フィンテックは高いレベルのセキュリティが求められるので、開発の上流工程から脆弱性の芽を摘みたかった | KENRO

24 時間いつでも・特に弊社の人と喋らずとも無料トライアルを利用できるサービスなので、お時間があるときにぜひご体験ください!

KENRO (ケンロー) | セキュアコーディングを当たり前にするエンジニアの学習プラットフォーム

🧪 Security Research / Vulnerability Disclosure

👀
そのとき筆者が気になったセキュリティ研究やソフトウェアの脆弱性についての情報を整理するセクションです

PinataHub: The Largest Archive of Leaked Credentials and Secrets in Public GitHub Repositories

IncognitaTech という(多分最近できた)OSINT 系スタートアップが、PinataHub という、パブリックな GitHub リポジトリ上のパスワード/シークレット類を検索するためのサービスを公開しています:

Introducing PinataHub: Explore the world of leaked secrets in GitHub.

サービスとしては GoldDigger というシークレット検知のためのバックエンドエンジンをもとに提供しているものらしく、”Intercepting Hail Hydra: Real-time detection of Algorithmically Generated Domains” のようなリサーチにインスパイアされたもののようですが、正直これ系の既存のツール/手法/サービスとの差分はわからず。そもそも自分が(広義の)Threat Intelligence 系の製品に詳しくないというのもあるのですが。IncognitaTech は引き続きウォッチしてみようと思います。

The Community Vote for the Top 10 Web Hacking Techniques of 2021 Started

毎年恒例 Top 10 Web Hacking Techniques of 2021 のノミネートが出揃い、現在 Top10 を決めるための投票フェーズに入っています。ぜひぜひ各ノミネートを確認してみて、面白かったリサーチに Vote しておきましょう 👍

https://portswigger.net/polls/top-10-web-hacking-techniques-2021

📶 Market

🏢 Startup

👀
セキュリティスタートアップに関する、acquisition や funding を中心にした雑多な動向を整理するセクションです

1Password Secured $620M in Series C Funding

1Password がシリーズ C の調達をリリースしています。本ラウンドのリードは ICONIQ Growth で、その他 Accel, Tiger Global, Lightspeed Venture Partners, Backbone Angels がフォローとして参加しています。

Bringing human-centric security to everyone | 1Password

future.1password.com では今後の 1Password の展望も図示されています。ところで human-centric security というフレーズ、最近結構使われてるなあ。

🗺️ Public Sector

👀
パブリックセクター(やそれに準ずるような組織)の動向を整理するセクションです

今週は特段面白い話は観測できませんでした。何かいい話があったら @lmt_swallow に教えて下さい!

✅ Wrapping Up

今週もお疲れさまでした。最近は改めて新型コロナウイルス感染症の感染が広がっている時期ですので、ぜひ皆様体調には気をつけてお過ごしください。

Share this article with: