セキュリティ~
このページでは、ログイン保護、APIキー、監査ログについて説明します。Web接続自体の暗号化に ついては、一般設定のHTTPS強制を参照してください。
パスワード要件~
パスワードは8文字以上で、文字・数字・記号のみを使用できます。よく使われるパスワード (password、qwerty123、およびクレデンシャルスタッフィング攻撃で使われる類似のリスト) は、この長さの条件を満たしていても拒否されます。
AoTは定期的なパスワード変更を強制しません。定期的な変更の強制は、もはや推奨される方法 ではありません — 本当に異なるパスワードを使わせるよりも、「Password1」「Password2」の ような予測可能な小さな変化に誘導しがちであり、ここでは求めていません。
アカウントロック~
あるアカウントでログイン試行が5回失敗すると、どのデバイス・ブラウザから試行されたかに 関わらず、そのアカウントは10分間ロックされます。カウンターはログインに成功するとリセット されます。この規則は、パスワードログイン、キーパッドログイン、そして以下の2要素認証コード にも同様に適用されます — 誤ったコードも誤ったパスワードと同じように数えられます。
これらの上限値は固定値であり、現在は設定として画面に公開されていません。
2要素認証(TOTP)~
AoTは、Google Authenticator、Authy、1Passwordなどのアプリが生成する標準的な6桁・30秒の コード(RFC 6238 TOTP — これらのアプリが他のサービスで既に使っているのと同じ標準)を 使った、2つ目のログイン要素に対応しています。
あるユーザーで有効にすると、ログイン時にまずパスワードを入力し、続いて認証アプリの現在の コードを入力する必要があります。どちらか一方だけでは足りません。
まだセルフサービスの登録画面はありません
現在のところ、ユーザー自身がこの機能をオンにできるページはAoTにありません — 計画はされていますが、まだ実装されていません。それまでは、管理者が直接設定する 必要があります(aot.utils.totp.generate_secret() でシークレットを生成し、 そのアカウントの totp_secret / totp_enabled = True を設定します)。 一度有効にすれば、他の設定なしに、上記のログイン動作がすぐに適用されます。
APIキー~
APIキーは、ブラウザセッションなしでHTTP APIへのリクエストを認証します。 管理 → システム管理 → ユーザー で対象ユーザーを編集し、APIキーを生成 で発行 します。
キーは生成された瞬間に一度だけ表示されます。 AoTはキー自体を保存せず、一方向ハッシュ のみを保存するため、設定ページで既存のキーを再度表示することはできません。生成した直後に 安全な場所へコピーしてください。紛失した場合は、新しいキーを生成してください — 古い値を 復元する方法はなく、新規発行すると同時に以前のキーは即座に無効になります。
キーは3つの方法で提示できます: X-API-KEY ヘッダー、HTTP Basic認証、または (非推奨 — API.md 参照)api_key クエリパラメータです。 キーを再発行すると以前のキーは即座に無効になるため、新しいキーを生成する前に、古い キーを使っているスクリプトや連携を更新してください。
監査ログ~
管理 → 監査ログ(システムログと同じ「ログを表示」権限が必要です — 既定の役割の うち、管理者・編集者・モニターはこの権限を持ちますが、ゲストやキオスクは持ちません。 役割を参照)は、誰が・いつ・どこから・何をして、 成功したかどうかを閲覧・絞り込みできる記録です。
何が記録されるか~
- ログインの成功・失敗・アカウントロック、ログアウト
- ユーザーの作成・変更・削除
- グループの作成・変更・削除、およびグループのメンバーシップや付与された対象への変更
- 一般設定の変更
- 装置の制御 — ダッシュボードから人が出力を切り替えた操作、AIエージェントがその人に 代わって行った操作、灌水シーケンスがバルブを開閉した操作。PID/PWMコントローラーと 環境コーディネーターによる継続的な自動制御は、意図的にここには含まれていません — 1行1動作の表に収めるには頻度が高すぎるためで、代わりに時系列の測定データのタグとして 追跡されます。ドライバー自体の起動・停止・削除も記録されます — ハードウェアの状態を 直接変え得るためです。
- APIキーの発行・失効、および非推奨のURLクエリ文字列方式によるキー認証の使用
- リモート管理トークンの発行
- この監査ログ自体をCSVとしてエクスポートした操作、およびソフトウェア更新の要求 (アップグレードページから直接行ったものと、予定された自動更新チェックによるものの 両方)
Action フィルターには、よく使われる項目のみが一覧表示されます。上記の更新要求の ような一部の一般的でない操作はそのドロップダウンには含まれていませんが、フィルターを All にすれば表示されます。
AIツールの呼び出しとその承認は、このログには含まれません — 別の承認記録として 残り、Safety & Approval Modelで説明されています。 このページには、その結果として実行された装置制御の操作のみが、AIによるものとして 記録されます。
表の読み方~
| 列 | 意味 |
|---|---|
| Timestamp | 発生した日時。ローカルのタイムゾーンで表示されます(内部ではUTCで保存) |
| Action | ドメイン.動詞 の形式のイベント名 — 例: login.failure、output.control |
| Result | success または failure。拒否された、または失敗した試行も、成功したものと同様に記録されます |
| User | ログイン済みのユーザーによる操作であれば、そのアカウント名。装置制御に関しては、代わりに何がその操作を引き起こしたかが表示されることがあります — シーケンス、ドライバーのライフサイクル段階(startup/shutdown)、または(予定された更新チェックの場合)auto-update |
| IP Address | リクエストの送信元アドレス。読み取れるブラウザリクエストが存在しなかった場合(AIエージェントによるコマンド、ドライバーのライフサイクルイベントなど)は空欄になります |
| Target Object | 何が操作対象だったか — その種類と、分かる場合はその名前(出力の名前、設定の名前など) |
| Detail | 短い自由記述のメモ。装置制御の場合、チャンネル、要求された状態、そして判定された発生元(user、ai、sequence、lifecycle、またはどの経路も出所を示さなかった場合は unknown — 表示されていたら確認する価値があります)が含まれます |
CSVエクスポートでは、画面には表示されない列が追加されます — user_id、target_id、 そして値の変化が意味を持つ操作(現在は設定変更)についてのみ入力される before/after のJSONです。
フィルタリングとエクスポート~
Action、User(部分一致・大文字小文字を区別しない)、Result で絞り込め、 表示する行数(Rows、最大1000)も選べます。Export CSV は、現在の Action/User/Result フィルターに一致するすべての行をダウンロードします — Rowsの上限は 無視されるため、ファイルには画面に表示されているより多くの行が含まれることがあります。
保存期間~
1年(AUDIT_LOG_RETENTION_DAYS)を過ぎたレコードは、毎日実行されるバックグラウンド ジョブによって自動的に削除されます。この期間は現在、設定ページから変更することは できません。
パスワード、パスワードハッシュ、APIキー自体が監査ログに書き込まれることは決してあり ません — 記録されるのは、ある操作が発生したという事実と、それを行ったのが誰かだけです。
リモート管理~
リモート管理は、1つのAoTインスタンスが他のAoTインスタンスのデータを表示できるように する機能です。/remote/setup に直接アクセスして使用します — 現在のところメインメニュー からはリンクされていません。
リモートホストを追加する際、そのホストのユーザー名とパスワードの入力を求められますが、 これは最初の1回だけの認証のためです。その後実際に保存されるのは、この目的のためにリモート ホストが発行した専用のアクセストークンであり、アカウントのパスワードやそのハッシュでは ありません。保存されたトークンが万一漏えいしても、影響を受けるのはそのホスト1台への リモート管理アクセスのみで、アカウント本来のログイン資格情報には影響しません。
この最初の1回のパスワードは、リモート側の証明書に対して検証された接続でのみ送信されます。 証明書は、資格情報を何も送る前にまず取得して固定(ピン留め)され、パスワードはその後、 この固定された証明書によって検証される接続でのみ送られます。以前のバージョンは順序が 逆でした — パスワードが検証されていない接続でまず送られ、証明書は応答本文から取得して 固定されていたため、中間者が誰でもパスワードを読み取り、その後のすべての接続に対して 自分の証明書を固定できてしまいました。
最初の接続の信頼性は、依然としてユーザー自身に委ねられています — 初めて見る証明書は、 何かと照合して確認することができません。そのため、ホストを追加する際には、固定された 証明書のSHA-256フィンガープリントが表示されます。接続を信頼する前に、別の経路で (リモートマシン自身で)これを照合してください。
その後、証明書が固定されたものと一致しなくなった場合、登録は中止され、何も送信されません。 リモート側が実際に証明書を入れ替えた場合は、そのリモートホストを削除してから再度追加して ください — 削除すると、古い固定情報も一緒に破棄されます。
既存のリモートホストはアップグレード後に再追加が必要です
このトークン方式が導入される前のバージョンからアップグレードすると、以前に追加した リモートホストが接続できなくなります。/remote/setup で各ホストを削除して再度 追加すると、新しいトークンで接続が再確立されます。