自動運転サービスという高い安全性を求められる領域での認証認可について。

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

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

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

4. 1. 会社紹介
4

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

26. © 2020 Tier IV, Inc. 26