開いている間と、閉じるとき
開いている領域は、サイクルごとに確認し直します。ドライブが抜かれた、トークンが差し替えられた・期限切れになった・廃止された鍵で署名されていた、あるいはアカウントの権限がなくなった。そのいずれかなら、その領域はロックされ、アプリケーションに閉じるよう指示が出ます。他のドライブで開いた領域は開いたままです。画面を閉じたりデータ操作を拒否したりするのはアプリケーションの役目で、Tetherlockはそのタイミングを伝えます。
ポートフォリオ → Tetherlock
システムとツール · セキュリティ設計の研究Tetherlock
Tetherlock
ローカルのワークスペース向けのアクセス制御コンポーネントです。ホストアプリケーションがワークスペースを開けるのは、3つの条件が同時にそろったときだけです。サインインしている人に入る権限があること、差し込んだドライブに署名済みトークンがあること、パスワードが一致すること。その後のチェックでドライブがなくなっていれば、アプリケーションにワークスペースのロックを指示します。
横にスワイプすると図の全体が見られます。
課題
ローカルのワークスペースには、開く条件に加え、必要なドライブがなくなったときにアクセスを終了するルールも必要です。
私の貢献
個人プロジェクトとして、アクセスのルール、鍵の設計、ロックのライフサイクルを定義し、設計レビューと実際の使用による確認を行いました。モジュールはAIコーディングエージェントが実装しました。
成果・検証への入口
実際のコマンドとテストの出力、鍵の設計判断を、ホストアプリケーションの責任と制約と併せて確認できます。
実際のコマンドとテストの出力を添えた、設計の解説です。ソースコードはGitHubで公開しています。録画や第三者による監査はありません。設計はしたものの証明できていない点は、このページにそう書いています。
概要
3つがそろえば開き、1つでも崩れれば閉じる
課題
ローカルのワークスペースには、機密性の高いファイルがあります。開いてよいのは、3つの条件が同時にそろったときだけです。サインインしている人に入る権限があること、正しいドライブが差し込まれていること、その人がパスワードを知っていること。そしてドライブが抜かれたら、すぐにまた閉じなければなりません。
- 担当範囲：ルールを定義しました。3つのゲート、抜いたらロック、バックドアなし、1本のドライブで複数の領域をそれぞれ別のパスワードで扱うこと、そして管理者パスワードを共有する代わりに保守を委任すること
- コードはAIコーディングエージェントが書きました。私は各設計を実装前にレビューし、実際に使ってテストしました
- モジュールを独立させる際、ロックの監視部分とトラストストアの処理は、同じルールに沿ってAIが書き直しました
ルールをひとことで
アカウントに権限がある+ドライブに署名済みトークン+パスワードが一致→ワークスペースが開く
ドライブを抜く→ロック · アプリケーションに閉じるよう指示
01
3つのチェックを、決まった順番で
アカウントに権限があること、ドライブに署名済みトークンがあること、パスワードが一致すること。アカウントに権限がなければ、パスワードの入力画面は表示されません。
02
ドライブを抜けば、ロック
開いているワークスペースは、チェックのたびに確認し直します。トークンがない、差し替えられた、または有効でなくなった場合は、そのワークスペースだけをロックします。
03
管理者パスワードを渡さずに保守を頼む
別の保守用トークンに、許可する内容をそのまま列挙します。セッションは初期設定では30分後に、またはドライブを抜いた時点で、自動的に終わります。
仕組み
1回のチェックサイクルと、1つの領域のライフサイクル
横にスワイプすると図の全体が見られます。
- アカウントに権限が必要。ホストアプリケーションが答える問いは1つだけです。このアカウントは、保護された領域を開いてよいか。この問いはサイクルごとに最初に確認されます。答えが「いいえ」なら入力画面は出ず、開いているものはすべてロックされます。
- ドライブに署名済みトークンが必要。署名、信頼済みの鍵、有効期限を確認します。トークンが特定のドライブに結びついている場合、別のドライブにコピーしたものは拒否されます。ただし比べるのはドライブのボリュームシリアル番号なので、完全な複製は防げません。
- パスワードの一致が必要。保存された検証用データと照合します。トークンにパスワードが含まれることはありません。
- パスワードの後に、ドライブをもう一度確認。トークンを読み直し、入力画面を出す前に見つけたものと同じでなければなりません。そのため、入力中にドライブを抜いたり差し替えたりしても、何も開きません。
横にスワイプすると図の全体が見られます。
保守の委任
別のトークンに許可する権限を列挙し、そのうちアプリケーションが認識するものだけを付与します。セッションはメモリ上にだけ存在し、初期設定では30分続きます。使うたびに時刻とトークンを確認し直し、ドライブを抜くと、次の操作の前にセッションは終わります。
実際の画面
独立版の7つの画面
新しく生成したデモ用の鍵で実行した、実際のコマンドとテストの出力です。撮影は2026-09-22と2026-09-26。パスは短縮し、ドライブのシリアル番号は隠しています。画面をタップすると原寸で開きます。
設計の判断
3つの判断と、採らなかった案
01
パスワードの後に、ドライブをもう一度確認する
パスワードの入力には数秒かかり、その間にドライブが抜かれたり、同じドライブ文字の別のドライブに差し替えられたりするおそれがあります。そこで、パスワードの後、何かを開く前に、トークンを読み直して検証し直します。
採らなかった案：入力画面の前に一度だけドライブを確認し、その結果をあとまで信用する。
02
マスターキーを作らない
復旧用の鍵も、迂回する経路もありません。アクセスを許可するコードは、パスワード確認の後にしか実行されません。その代償は受け入れています。署名鍵をすべて失えば、信頼の設定を一からやり直すことになります。
採らなかった案：「いつでも復旧できるように」という緊急用の解除手段。バックドアは、いちばん簡単な侵入口になります。
03
迷ったらロック
チェックが想定外のエラーで失敗したり、領域が開いている間にトークンが読めなくなったりしたら、まず領域をロックし、エラーはその後で報告します。そのため持ち主が、たまにロックを解除し直すことになるかもしれません。
逆に、誰かが確認するまで開いたままにすると、誰も気づかない間ずっと扉が開いたままになります。
範囲と制約
すること、ほかに任せること
Tetherlockが決めるのは、保護されたワークスペースを開いてよいかどうかです。そして、それを再び閉じます。中のファイルは暗号化しません。ワークスペースのパスワードは確認しますが、暗号鍵ではありません。ドライブの中身を読めないようにするのは、ディスク全体の暗号化の役目です。また、ドライブと、それをビット単位で完全に複製したものとを見分けることもできません。
できていること
- 署名済みトークン、パスワードの検証用データ、ドライブへの結びつけ
- 鍵の入れ替えに対応したトラストストア
- 解除とロックの監視
- 保守の委任
- 解除後のモジュール読み込み
- 暗号化した受け渡し用パッケージと、管理者用のコマンドラインツール
検証済み · 2026-09-26
- Python 3.10と3.14で143件のテストが合格、1件スキップ
- 新規インストールとREADMEのクイックスタートが最後まで動作
- 監視部分の保護を1つずつ外すと、毎回テストが失敗
まだのこと
- ワークスペースのファイルの暗号化
- 失効リスト
- 第三者によるセキュリティ監査
- ユーザーインターフェース。画面はアプリケーション側が用意する
- 抜いてからロックまでの実際の時間：未計測
こうした考え方をチームに求めているなら、同じ発想はAI Control Centerにも表れています。そこでは承認は、承認したときとまったく同じ版に対してだけ有効です。