DASに設定するMC認証ユーザにadminを指定してはいけない理由。

はじめに

みなさん、DASに設定するMC認証ユーザに何を指定していますか？
おそらく多くの人は構築手順書に記載の以下画像を見て admin ユーザを指定していたりするのではないでしょうか？実害はないのかもしれないですが、運用観点では止めてほしい。。

本稿ではなぜ admin ユーザを指定してはいけないのか、代わりに何を指定すべきなのかについて書いて行こうと思います。

一部手順書内の画像は確かに admin ユーザが指定されていますが、手順として 「admin ユーザを指定しましょう」という記述は一切なく、項目の説明として「MCのユーザー名」とあるのみです。
とはいえ参考として添えられる画像に admin と書いてあるのだもの、何も考えずに admin ユーザを指定してしまう人も多いのではないでしょうか？私のように。

それでも admin を指定するとどうなる？

下図のようにMCのログインカウントが爆増します。
利用者の状況を確認しようかな。とManagement Console（MC）を覘いた瞬間に、admin の突出したログイン数に度肝を抜かれます。

運用メンバーのログイン数と比較しても桁が2つ違いますね。。

そもそも強力な権限を持つ admin アカウントは日常的に利用するものではありません。初期値として用意されている万能なユーザーなのでテストや検証でサッと利用したい場合に軽い気持ちで利用しがちですが、本番環境に適用してはいけません。

サーバなど専門家が構築するシーンでデフォルトの管理者アカウントが本番利用されることは考えにくいですが、DASについては業務端末へのセットアップを利用者部門や経験の浅いRPA担当が代行する場合も多く、このあたりの考慮なしに情報を設定してしまいがちです。

最近はどうか知りませんが、以前は導入前の検証環境をそのまま本番転用しているケースが多かったようです。そういった環境、状況においてはデフォルトの admin アカウントが多用されていそうで怖いですね。

次に、これだけアクセス数が多いと不正アクセスの有無に気づけなくなります。
MCには監査ログ機能が存在し、すべてのMCへのアクセス（誰がいつどの機能に何をした）を記録可能ですが、これだけの数アクセスが発生している状態で、しかもほとんどが問題のない接続だと思っていたら異常に気付くことは難しいのでは？と思います。

運用監視効率化のためにもノイズとなるものは排除したいです。

対策

Step1. まずやること

デフォルトの管理者アカウントは使用しない。
BizRobo!に限らず全てのシステム（個人用途では自宅の無線Wi-Fiルータも）において、セットアップ時にデフォルトセットされている管理者アカウントのパスワードは変更しましょう。

MCログイン後の画面からパスワードの変更を選択して操作を行うことができます。

変更後のパスワードはパスワードマネージャなどのシステムを使って厳密にRPA推進組織内で管理することをお勧めします。

また、必須ではありませんが不正アクセスへの対応として以下の様に設定ファイルを編集することでログイン試行回数と次の試行までの待ち時間に制限を掛けることができます。
\WebApps\{mc}\WEB-INF\spring\authentication.xml 内のloginAttemptServiceを編集。

<bean id="loginAttemptService"
      class="com.kapowtech.scheduler.server.spring.security.LoginAttemptService" 
      lazy-init="true">
  <constructor-arg type="boolean" value="true"/> # 以下を有効化
  <constructor-arg type="int" value="3"/> # 3回失敗したら
  <constructor-arg type="int" value="10"/> # 10分間停止
</bean>

ロック時の表示

Step2. 用途に適したアカウントの準備と割り当て

以前の投稿でも書いた通り、DASに設定するMC認証アカウントにMCの操作権限は必要ありません。

DASからMCへの通信はDASの情報をMCに登録することが目的なので、正規のユーザとして認証可能であれば十分です。

DASに設定するMC認証ユーザとしてはまずMCにDAS専用のログインユーザとグループを作成し、次に DAS Client User としてプロジェクトに登録します。

プロジェクトロール	説明	対象
DAS Client User	DAS クライアント ユーザー (このユーザーは API 経由でサービス認証としてのみログインします): これはリモートの Desktop Automation Service (DAS) クライアント用に作成されたユーザーで、DAS API へのアクセス権限のみを持ちます。DAS クライアント ユーザーには DAS を Management Console に提示し、DAS 構成を取得する権限があります。	DAS (システム)

DASの数が多い場合にインスタンス¹の数だけMCのログインユーザを作成して管理するのはメリットよりも管理工数等のデメリットの方が大幅に上回ると思うので、全体で1つのDAS専用ユーザアカウントを作成して共有するか、DAS端末の主幹や管理が複数存在する場合にはその単位で共有アカウントにするのがいいと思います。認証するだけのアカウントなので。

DAS自体は特定のプロジェクトに縛られずMC全体で共有されるものなのに、DASに設定するMCユーザは特定のプロジェクトに所属させる必要があるのは不自然。という意見があるかもしれません。
確かに釈然としない感じはありますが、将来的に「プロジェクトに依存しない権限が設定できるようになる」または「DASがプロジェクトごとに管理できるようになる」予兆なのかもしれない。と思って様子を見てみましょう。

DAS専用ユーザ情報を設定する

DASのMC認証用ユーザをDAS設定画面に指定します。

まとめ

BizRobo!の動作に直接影響しない要素であるだけに、見落とされがちな話でした。
基本的にRPAの基盤は企業ネットワーク内に閉じた構成になることが多いのでセキュリティについても割と甘く考えられがちではありますが、ゼロトラストネットワークの考え方に沿って各モジュールごとのセキュリティについても最低限意識はしていきたいですね。

1. 端末ではなくインスタンスとしている理由は、DAを Windows Server や 仮想マシン上に構築する場合、1台の端末に複数のログインユーザ分DASがセットアップされ、複数の実行環境（インスタンス）が生成されるためです。 ↩