自動運転サービスの認証認可

自動運転サービス の認証認可 K. Hoshi April 1st, 2021 1

Profile Kotaro HOSHI * 認証認可基盤の開発 * 分散シミュレーション基盤の開発 * 遠隔運転システムの開発 GitHub: @rxnew 2

Agenda 1. 2. 3. 会社紹介 Web.Auto のアクセス制御 Web.Auto の認証認可基盤

1. 会社紹介 4

Tier IV 自動運転 OS Autoware の開発 工場内物流 タクシー

Vision Tier IV Vision Intelligent Vehicles For Everyone. 自動運転に資するあらゆるテクノロジーを解放し、 様々な組織、個人がその発展に貢献できる 持続的なエコシステムを構築。 Web.Auto Vision Intelligent Vehicle Solutions For Everyone. IoT・Cloud技術を用いて、様々な組織・個人が 簡単に自動運転テクノロジーにすぐにアクセスし、 その技術で抱えている課題を解決する基盤を提供。 6

Apps 運行管理 地図作成 遠隔監視/操縦 車載 シミュレーションシナリオ作成 自動運転ソフトウェア評価

2. Web.Auto のアクセス制御 8

命に関わるオペレーション クローズドコースでの遠隔操縦

命に関わるオペレーション 車両の発車指示 Web アプリのボタン一つで車両を発車させることができる 車両の遠隔操縦 自動運転システムの判断をオーバーライドする形で遠隔地から車両を操縦できる 地図の編集 地図の信頼性は自動運転システムの信頼性に大きく影響する 自動運転ソフトウェアの Over The Air アップデート Web アプリからソフトウェアパッケージを配布 /アップデートできる アクセス制御は重要

どう制御するのか 例えば遠隔操縦で考えると、 ロール 属性 実証実験のメンバー？ 二種免許が必要？ 保険会社のオペレータ？ 社内独自の認定資格が必要？ 未知なことだらけ

変更に強いアクセス制御 ロールを検証する // 保険会社のオペレータかどうか if user.hasRole("保険会社のオペレータ ") {...} => “実証実験のメンバー ” ロールが追加されたら …？ パーミッションを検証する // 車両を発車させるパーミッションがあるかどうか if user.hasPermission("車両を発車させる ") {...} 属性の話はここでは触れません

ロールテンプレート ABAC も考えられるがここでは扱わない 特定のリソースに絞ったパーミッションを設定したい => ユーザ定義ロール 例. 保険会社 X のオペレータロール：車両 1 を発車/停車させる 保険会社 Y のオペレータロール：車両 2 を発車/停車させる しかし… アプリ内部で呼ぶ API が増えて追加のパーミッションが必要になった時、 ユーザがロールを更新しないといけない リソースをパラメタライズする => ロールテンプレート 例. 保険会社のオペレータロールのテンプレート：車両 ${vehicle_id} を発車/停車させる

組織を横断した権限管理 複数の組織が共同で実証実験を行ったり、サービスを展開したりする Requirements: 他の組織のメンバーの管理はしたくない 他の組織のメンバーの退職事情 などに振り回されたくない 各組織が勝手に権限を付与できては困る 多くの場合一つの組織がオーナーになる 非エンジニアでも管理できる AWS のクロスアカウントアクセスのような複雑な手順は踏みたくない

組織 x プロジェクト 組織 = 人を管理する箱 プロジェクト = 権限を管理する箱 組織毎にグループ管理 グループ単位でプロジェクトに参加 プロジェクトオーナーがグループにロールを割り当て

3. Web.Auto の認証認可基盤 16

Web.Auto Architecture User Service layer T4 Account Web.Auto Console Autoware Vehicles Console Autoware Simulator Autoware Map Tools Vector Map Builder Vehicles Console CI Tools Autoware FMS Autoware Drive Autoware Calls FMS Console Drive Map Store Calls FMS API Web Docs Autoware Go Go Field Operation App Stats Projects Vehicles Scheduler Autoware OTA Vector Map Registry OTA FMS Sim Route Search Web.Auto Auth Core Service layer FOA Autoware Adapters Edge layer Edge

最初は認証だけだった 二つの Identity Provider (IdP) / OpenID Provider (OP) エンドユーザが自身のアカウントでロ グインするアプリ => T4 Account (内製) 車内やバス停などに置かれるアプリ => Amazon Cognito

認可サーバのアクセストークンの払い出し OP のアクセストークンを認可サーバのアクセストークンに交換 以降単に “アクセストークン ” または “トークン” と書いた場合は認可サーバのアクセストークンを指す バックエンドの API を呼ぶときに使用 バックエンドはどの OP で認証されたのか知る必要はない 1. 2. 3. 4. 5. OP のアクセストークンを取得 OP のアクセストークンを認可サーバに渡す 認可サーバは OP の UserInfo エンドポイントを使用してサブ ジェクトを特定 認可サーバはアクセストークンを発行 アクセストークンを使用して API 呼び出し

エージェント型 vs プロキシ型 エージェント型 アプリ側で 2 種類のアクセストークンを管理 しなければならない プロキシ型 e.g. Identity Aware Proxy 各プロトコルのプロキシをサポートする必要 がある Web.Auto では WebSocket/WebRTC/gRPC-web など様々なプロトコルを 使用しているのでエージェント型を選択

トークンのスコープは RBAC のパーミッション プロジェクトA プロジェクトB 車両オペレータロール (全ての車両の発車/停車が可能) 地図作成ロール (全ての地図の作成/編集が可能) スコープを絞ることも可能 この例は実際のアクセス制御とは異なります

スコープの検証 API の認可 アクセストークンのスコープに必要なパーミッションが含まれるか検証する しかし… パーミッション解決ロジックを各 API サービスに持たせたくない ワイルドカード `*` があるため少々複雑 使用言語が統一されていないので SDK 提供も難しい スコープが長くなるので JWT に埋め込みたくない パーミッションが数十個つくとこはざらにある サイドカーパターンに限定したくない AWS Lambda backed な API もたくさんある

スコープ検証エンドポイント 各 API サービスはスコープ検証エンドポイントを叩く 高頻度のアクセスに耐え得る設計 ● ● ● 1 リクエストにつき DynamoDB のクエリ一回 DynamoDB Accelerator を噛ませることも検討中 gRPC / Transit Gateway

Client Credentials Grant アプリケーション自身がサブジェクトとなって認可を受けたい バッチ処理のようなエンドユーザが起点となっていないとき エンドユーザが直接呼べない内部 API をシステム権限で呼ぶとき 3rd Party アプリから Web.Auto に接続したい OAuth を使用した Twitter クライアントを作るのではなく、 API キーを発行してアプリを作るイメージ OAuth 2.0 の仕様 (クライアント認証方式 : client_secret_post/private_key_jwt) に準拠しているので OAuth 2.0 のクライアントライブラリを流用できる

今日話していないこと ● ● ● ● ● ● ID 連携 3rd Party アプリ + OAuth クライアントアプリの識別 契約に基づく認可 フロントエンドの画面出し分け グローバル展開 他にも色々やっています & これからやっていきたいので 興味がある方はぜひ応募してください！

© 2020 Tier IV, Inc. 26