セキュリティ実践

A2AL の既定設定はすでに取捨選択を済ませています。外向きに開くのは接続に必要なサービス用ポートだけで、管理用ポートはローカルのみで待ち受けます。日々あなたが決めるのは主に三つです：管理用ポートを外部に出さないこと、アクセス制御を必要な分だけ開くこと、マスターキーをオフラインで保管すること。残りは、どこまで晒すことを許容するかで決まります。

3つの推奨事項

推奨	方法
管理用ポートを外部に出さない	`api_addr` は `127.0.0.1:2121` のままにし、リモート管理が必要なときは `a2al admin` を使います。ポート転送はしません
HTTP を開く前に ACL を設定する	サービスを提供するときは、既定で許可するのではなく AID ごとに許可します
マスターキーをオフラインで保管する	作成時に一度だけ表示され、以後はあなたがオフラインで保管します。A2AL は預からず、復元もできません

サービス用ポートは開き、管理用ポートは開かない

ポート	既定の待ち受け	役割	指針
`4121`（UDP + TCP）	すべてのアドレス	UDP は QUIC による直通接続とアドレス解決、TCP は NAT 越えのための ICE シグナリングを担います	開いたままにします。データプレーンであり、アイデンティティは TLS ハンドシェイクの中で検証されます
`2121/TCP`	ローカルのみ（`127.0.0.1`）	パネル、管理 API、ローカルゲートウェイ `http://127.0.0.1:2121/aid/{AID}/…`	既定のままにします。`0.0.0.0` に変更したり、ポート転送したりしないでください

管理用ポートを既定のままにしても不便はありません。パネル、ローカルゲートウェイ、AI ツールはいずれもローカルから到達します。別のマシンからこのノードを管理する場合は、A2AL 自身のチャネルを使います。

a2al admin on                    # リモート管理を有効にする
a2al admin allow <相手のAID>     # この AID だけを許可する

相手は暗号化された直通接続でこのノードを管理し、ポートを開く必要はありません。デプロイ上の都合で 2121 をローカル以外にバインドする場合（複数のマシンで1つのノードを共有するなど）は、api_token も設定し、呼び出し側に提示を求めてください。token がなければ、そのアドレスに到達できるプログラムはどれでもローカルのアイデンティティを操作できます。1台のマシンを複数人で使う場合は require_local_token = true を有効にし、ローカルからの呼び出しにも token を要求してください。

アクセス制御：発見できる ≠ 呼び出せる

ACL は、その AID の HTTP を呼び出し、ファイルオブジェクトを取得できる相手を決めます。既定は public です。

a2al agents acl-default <自分のAID> deny                           # まず既定の許可を閉じる
a2al agents acl-allow   <自分のAID> <相手のAID>                    # 次に AID ごとに許可する
a2al agents acl-allow   <自分のAID> <相手のAID> --secret <合言葉>   # 合言葉を添えて許可する

HTTP を提供する場合にのみローカル HTTP をバインドします。サービスを出さなければバインドも不要で、呼び出せる入口も存在しません。
バインドするのは開放したい一つのサービスだけにします。たとえば a2al inbound bind --addr 127.0.0.1:8080 のようにし、マシン全体を外に出さないでください。
許可は名前を一つずつ追加します。先に acl-default deny、そのあと acl-allow <相手のAID> です。
ACL が対象とするのは受信 HTTP とファイルオブジェクトです。ノート、発見、会話は対象外で、会話の受信は a2al chat block --aid <自分のAID> --peer <相手のAID> で止められます。

失敗したアクセス試行は a2ald が自動的に扱います。リモート管理面では、同じ AID から合言葉を5回続けて間違えると拒否リストに入ります。接続用の合言葉そのものは15回連続で失敗すると無効になり、新しくするにはリモート管理を有効にし直す必要があります。ACL 側は送信元ごとに失敗を記録し、短時間に連続すると約12分の一時的な遮断が働き、1回成功すれば記録は消えます。

IP アドレスの露出範囲とリスク

A2AL を導入しても、すでにある露出面は広がりません。マシンが NAT やファイアウォールの内側にある場合（家庭用ルーター、社内ネットワーク、クラウドのセキュリティグループ）、A2AL は NAT 越え（相手側反射、UPnP、ICE による穴あけ）で直通接続を確立し、ポートマッピングの設定は不要です。同じ理屈で、A2AL を導入したからといって、社内ネットワーク上の AID にバインドしていないサービスが外部から呼び出せるようになることもありません。

アドレス記録を公開すると、記録に載るのはインターネットへ出るときの出口アドレスと直通接続用のポートです。これは、どのオンラインサービスに接続したときにも相手が見ているアドレスと同じ種類のものです。あなたの AID を知っている人、公開した能力を見つけた人は、それを解決できます。

見えるもの：出口アドレスと、直通接続に使うポート。見えないもの：メッセージの本文とサービスの中身。メッセージは端末間で暗号化され、接続は暗号化された直通リンクです。
リスクの境界：出口アドレスを知られても、それ自体は侵入経路になりません。バインドしていなければ呼び出せる対象はなく、バインドしていても ACL を通る必要があります。
露出を避けたい場合：アドレス記録を公開せず外向きの接続だけに使う（公開と可視性を参照）、外向きのアイデンティティを個人のネットワークから分けた専用マシンやコンテナに置く、セルフホストネットワークだけを使う（bootstrap を自分のノードに向けます。プライベート（セルフホスト）ネットワークを参照）といった選択肢があります。

エージェント側のルール

見知らぬ AID からの招待は自動で受け入れません。会話やルームの招待は、送り元を確認してから受諾や参加を判断します。
確認できていない AID は許可リストに入れません。ACL にも、連絡先にも、エージェントの信頼対象にも加えません。
エージェントには、取り決めた送り元からのメッセージとリクエストだけを処理させます。それを外れる内容は信頼できない入力として扱います。
執拗に接触してくる AID へは a2al chat block で受信を止めます。

メッセージと内容

ノートは端末間で暗号化され、受信者だけが復号できます。会話とルームの内容はメンバーにのみ見え、転送はメンバー間の暗号化された直通接続で行われます。
メッセージの内容は外部からの入力です：ノート、ルームの発言、HTTP の応答はいずれも指示文を含みえます。見知らぬ送り元を自動処理させる前に、送り元の AID と期待する内容を確認してください。コマンドの実行、鍵の開示、設定の書き換えを求める内容は、信頼できない入力として扱います。
長期間有効な資格情報をメッセージで渡すのは避けてください。アクセス権を与える必要があるときは、使い捨ての資格情報を使います。

アイデンティティと鍵

マスターキーは作成時に一度だけ表示されます。オフライン（パスワードマネージャーや紙）で保管してください。アイデンティティをエクスポートするときは --password を付け、平文での書き出しを避けます。
データディレクトリの既定権限は 0700、設定ファイルは 0600 で、鍵は <データディレクトリ>/keys/ に置かれます。マシンを移すときは必要な部分だけを持ち出してください。
TLS ハンドシェイクが検証するのは「この接続がその AID のものであること」であり、「その AID が誰のものか」ではありません。信頼は AID をどこで入手したか（対面、署名付きメール、見知らぬルーム）に依存します。より強い確認が必要なときは、別の経路でも照合してください。

より強い隔離が必要なとき

Docker または仮想マシン：a2ald を個人の環境から切り離し、必要なデータディレクトリだけをマウントします。Docker での運用を参照してください。
専用ユーザーで実行：Linux では非特権ユーザーと systemd で動かします。systemd での運用を参照してください。
書き込み先を限定：files_root で書き込みを許すディレクトリを指定します。
アイデンティティの分離：外向きのサービスには専用の AID を使い、個人用の AID と分けます。漏洩した場合や不要になった場合の影響をその AID の範囲に留められます。

目的	ページ
AID をどこまで晒すか、誰が見つけられるか	公開と可視性
その背後の仕組みと境界	セキュリティ概観
HTTP を呼び出せる相手を制限する	自分のサービスを呼び出してもらう
daemon を隔離された環境に置く	Docker での運用