[実験室] DASのデバイス登録アカウントにおける所属プロジェクトと権限の意味を考える。

## はじめに

先日ふと思いました。
DAS（Desktop Automation Service）に設定する MC（Management Console）接続アカウントへ、非常に弱い権限のユーザーを指定したらどうなるのだろうかと。

ちなみにRoboserverの場合「Kappletの利用」のみ可能な権限の弱いユーザーを指定して起動すると、以下の様に「権限足りないよ～」というエラーが出力されMCに接続できません。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3090491/a5a98a78-cf1b-900d-66d4-66d1c4b94caf.png)
一方で Design Studioの場合は上記と同じユーザーを指定してもエラーになることなく、Design Studioを起動できます。

これはどんな違いがあるのか、DASの場合はどうなるのか、実験してみました。

## DASの接続形式を整理する

DASとはロボットがデスクトップ上のアプリケーションを操作する場合に利用する端末側エージェントのようなもので、ロボットがDASに接続する方式には以下の2種類があります。

- デバイスマッピング方式
- ダイレクトアクセス方式
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3090491/a80c1f35-9357-92e3-1c86-2f8fb64e0bed.png)

何となく惰性で（？）よく使われるのは`デバイスマッピング方式`で、上図のようにMCへDASを事前登録しておき、ロボット実行時にピックアップします。

一方で`ダイレクトアクセス方式`は事前にMCへ登録する必要なく、ロボットの実行時に直接アクセスします。

言い換えると`デバイスマッピング方式`は出勤常駐型であり、`ダイレクトアクセス方式`は直行直帰型とも言えます。
具体的に比較すればそれぞれに長所・短所や使いどころがあるのですが、今回は触れません。

:::note
端的に言えば `デバイスマッピング方式` の場合は登録されているすべてのデバイスが常に Windowsログインした状態（画面はロック）で待機しており、ロボットの実行前後の状態をキープします。
ゆえに、呼び出されてすぐにデバイスを操作することができたり、登録しているすべてのデバイス状況（稼働中/オンライン/オフライン）を管理側で把握することができます。

`ダイレクトアクセス方式` の場合はデバイスが必要になったタイミングでデバイスを直接指定してWindowsログイン（場合によっては再起動）をするため、呼び出してから操作可能になるまでのオーバーヘッドが必要となる一方、常にクリーンアップされた状態でデバイスの操作ができるというメリットがあります。
:::

今回実験をするのは `デバイスマッピング方式` を採用するDASについてであり、以下の画面にデバイス登録情報を入力します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3090491/d9eac9d9-5005-83f0-33b4-61097db8ada8.png)

## デバイス登録の実験

MCにDASをデバイス登録するために、MC接続ユーザーとして権限が限定されたユーザー（pj2）を指定します。
「pj2」はMC内の一部のプロジェクトのみアクセス可能なユーザーで、MCにログインすることはできますが以下の通りほぼ何の操作もできません。（項目が表示されない）
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3090491/286f0fb7-c495-2888-5804-6b960997a161.png)

一方で、登録したDASは以下の様に（管理者ユーザーでログインして表示）デバイスとしてMCに登録され、DASの稼働情報もログとしてMCに集約されるようになります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3090491/ab44c8b0-6aab-ba00-f0dc-e64a90a494b3.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3090491/f5e63858-6660-0979-5cb7-5f6f17a423c5.png)
デバイス登録されたDASはMCの管理メニュー配下「デバイス」画面から確認することができます。

デバイスはMC全体の共有リソースとして管理され、どのプロジェクトからでもデバイスマッピングにより利用することができます。

:::note
プロジェクト毎に使用デバイスを分けたい場合、機能的に強制することはできませんが、ラベルの命名を工夫することである程度デバイスマッピングによるコントロール・防止が可能です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3090491/47a3a943-a149-d9cd-0d4c-2f4554b1abbe.png)
デバイスマッピングでは、「MCに登録されているDAS」と「ロボット内で指定されたDASのエイリアス」を紐づけることでロボット実行時に接続するDASを決定します。
開発用DASと本番運用DASを混同しないためにロボット内での定義とMCの情報をマッピングする仕組みとなっており、多くの場合開発時には「シングルユーザーモード」で `ダイレクトアクセス方式` によるDASの操作を行います。

運用観点では、運用対象ではない開発端末まで運用監視対象のMCに接続されてログが混ざることは避けたいので、開発/ステージング用のMCを別建てして運用するようなケースでなければ上記のような使い分けを希望します。
:::

## 実験結果

実験というほどではなく、単にやってみた程度の話ではありますが、Design Studioと同様でMC接続用アカウントの権限はデバイス登録に影響しないことがわかりました。

## 考察

よくよく考えてみれば明確なのですが、MC接続用アカウントの権限というのはMCの操作に対する「認可」の話であり、Design StudioやDASがMCを操作するわけではないので「認証」ができれば認可の必要はない[^1]。ということですね。

一方でRoboServerについてはそうは言い切れないかな？という点と、そもそもRoboServerは位置づけが違うと思う点があり、「意見」として理由を整理しておきます。確証はないです。

- v11.3 現在では過去の「MCを前提としない」時代のAPIがいまだに残っており（いつか廃止されるでしょう）、MCに対してより強い関与をしているから。（知らんけど）
- Design Studio や DASと異なりバックグラウンドでサービス実行することを前提としたサーバー機能であり、システムが実施対象とするあらゆる処理を実行可能な最低限の権限（管理者権限/システム権限）を付与することが必要なため。

## 結論

DASのデバイス登録におけるMC接続情報はライセンスサーバ（MCのこと）との「認証」を行っているだけで、MC内に登録された正規のユーザーであることが証明できれば、その権限や所属は関係ない。

:::note warn
登録ユーザーの権限は問いませんが、プロジェクトに所属した有効なユーザー情報である必要があります。
ユーザー情報が有効（MCにログインできる）とは、
- ユーザー情報が存在する
- ユーザーがグループに所属している
- グループ（セキュリティグループ）がプロジェクトに参加している

ことが必須です。
（なお、adminユーザーについてはその限りではありませんが、セキュリティ的にadminを個々のDAS設定に利用するのは避けた方がいいでしょう。）
:::


[^1]:https://www.trustbind.jp/column/20210331.html