セキュリティ

認証

アカウントは、メールアドレスとパスワード、Google OAuth、またはGitHub OAuthを使ったSupabase Authによって管理されます。ログイン後、ブラウザはセッショントークン（JWT）を保持し、プラットフォームのミドルウェアによって自動的にリフレッシュされるため、作業中にセッションが黙って期限切れになることはありません。

APIはこのセッショントークンを2つの形式で受け付けます。ダッシュボードがどのみち送信するセッションクッキーとして、またはAuthorizationのBearerヘッダーとしてです。ブラウザログインなしのプログラムからのアクセスには、代わりにAPIキーを使用します（後述）。有効な認証情報のないリクエストはエンドポイントに拒否され、ヘルスチェックやお問い合わせフォームなど、明示的に公開されているルートのみが、認証なしで動作します。

ロールと権限

すべてのアカウントは、CLIENT、OPERATOR、ADMINのいずれか1つのロールを持ちます。クライアントはロボットを所有してセッションの料金を支払い、オペレーターはロボットを操作してセッションから収益を得て、管理者はプラットフォームを運営します。クライアントとオペレーターはオンボーディング中に選択しますが、管理者ロールはプラットフォーム管理者によって割り当てられ、自分で選択することはできません。

ロールチェックは、UIではなくすべてのリクエストに対してサーバー側で行われます。APIの下層では、データベースアクセスも行レベルセキュリティポリシーによってさらに制限されているため、エンドポイントにバグがあったとしても、それが他のアカウントの行への自由なアクセスに直結することはありません。

APIキー

APIキーは、ブラウザログインなしでスクリプトやサーバーにアクセスを提供します。/dashboard/settingsで作成・失効でき、キーにはayr_live_というプレフィックスが付き、AuthorizationのBearerヘッダーとして送信します。キーは、それを作成したアカウントのロールと権限で動作するため、キーの漏洩は、パスワードの漏洩とまったく同じくらい深刻です。

• キーはサーバー側にのみ保管してください。クライアント側のJavaScript、モバイルアプリ、公開リポジトリに置くべきものではありません。
• 連携ごとに1つのキーを使用してください。何かが漏洩したとき、1つの利用者だけを失効させたいはずで、すべてを失効させたくはないはずです。
• ダウンタイムなしでローテーションしましょう。まず新しいキーを作成してデプロイし、その後、古いキーを/dashboard/settingsで失効させます。
• 少しでも疑いがあれば即座に失効させてください。新しいキーの作成には数秒しかかかりませんが、有効なキーを持つ攻撃者は、あなたのアカウントでできることは何でもできてしまいます。

ライブ制御中の安全対策

ライブ制御は、セッションのリースに紐付けられています。ロボットは、正確に1つのACTIVEなセッションの間だけ、かつそのセッションを保持しているオペレーターからのみ、コマンドを受け付けます。ロボット自体は、それ以外の全員に対してはIN_SESSIONと表示されます。1人のオペレーターが同時に保持できるACTIVEまたはPAUSEDのセッションは最大1つであり、これにより1人が名目上2台のアームを同時に制御するといった事態が排除されます。

コックピットには、アームを即座に停止する緊急停止があり、セッションを一時停止または終了すると、コマンドの流れ全体が止まります。それに加えて、プラットフォームはオペレーターのアクティビティを監視しており、一定時間入力がないと非アクティブ警告が送信され、それでもオペレーターが非アクティブなままであればセッションは自動的に停止されます。これは両側を保護します。クライアントをアイドル時間への課金から守り、ロボットを、有効なリースを保持したまま制御不能な状態に置かれることから守ります。

監査ログ

すべてのセッションは、開始と終了、一時停止と再開、アクティビティチェック、非アクティブ警告、オペレーターの交代、延長リクエスト、エラーを、それぞれタイムスタンプ付きでイベントログとして保持します。異議申し立てが審査される際、このイベントログが主要な証拠となります。これも、プラットフォームが誰かの記憶に頼るのではなく自動的にログを書き込む、もう1つの理由です。

セッションを超えて、重要なプラットフォームの操作は、実行したユーザーid、操作内容、対象リソース、メタデータとともに、監査ログに記録されます。プロフィールの変更、支払いに関わるトランザクション、管理者の操作はすべて記録が残ります。監査記録はプラットフォームによって書き込まれ、ユーザー向けのどのインターフェースからも編集できません。

暗号化とデータ保護

プラットフォームとの間のすべての通信は、映像ストリームと制御信号を含め、転送中はTLSで暗号化されます。データ層では、行レベルセキュリティポリシーがアカウントごとにデータベースアクセスを制限します。支払いデータは、最も明確な境界線です。カード情報と銀行情報の処理はStripeが専任で行い、AY-Robotsのサーバーには一切触れません。

脆弱性の報告

セキュリティ上の問題を見つけた場合は、/securityページ、または/contactフォームのBug Reportカテゴリを通じて、責任を持って報告してください。何を、どこで見つけたか、どうすれば再現できるかを含めてください。問題を実演するために必要な最小限を超えて他のユーザーのデータにアクセスしないでください。また、私たちが対応する合理的な機会を得る前に詳細を公開しないでください。すべての報告に目を通しています。

よくある質問