2
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

それでもまだ `net use` 使いますか?ファイルアクセスをセキュアに保つ RFS のすゝめ

Last updated at Posted at 2023-06-26

はじめに

ロボットが操作するファイルって、どうやって管理してますか?

  1. ロボットが動作する端末/サーバのローカルに配置
  2. 会社のNAS/SAN(ファイルサーバ)上の共有フォルダに配置
  3. BOX や Google Drive などのオンラインストレージに配置

が一般的かな?と思います。

なかでも「ファイルサーバ上の共有フォルダ」に配置されたファイルへは、ロボットから net use コマンドで接続しているケースが多いのではないでしょうか。

今回は net use を使い続けることによる課題と、解決案としての RFS について書いて行こうと思います。

本記事は、BizRobo! v10.7.x 以降の利用を前提に解説します。

net use が使われる よくある背景

ロボットを全社的に利用しており、部署毎個別にアクセス権限が設定されているフォルダへロボットのアクセスを許可する場合、

  1. 既存のロボット実行アカウントにアクセス権限を追加する
  2. 当該フォルダへのアクセス用に新規でアカウントを作成し、ロボットに付与する

のいずれかが考えられますが、セキュリティの観点から多くの会社では後者が選択されるでしょう。

これは最小権限の原則というセキュリティの基本原則に基づいており、「管理工数がかかるから特権アカウント付与しちゃいましょうよ。」というのはダメなんですね。

そうなるとロボット実行ユーザのアカウントとは別に、ファイルアクセス用アカウントを準備・管理しながらロボットを動かすことになります。

また、ロボットの実行タイミングとは別に端末やサーバ 1 上にあらかじめ複数アカウントのリモートドライブ接続をしておくことで、ファイルアクセス用のアカウントを意識することなく複数部署のファイルへアクセスすることができますが、根本的にこれではロボット実行ユーザーに過大な権限を持たせているのと同義で、最小権限の原則から外れてしまいますし、脱法的な運用をしている分、特権アカウントを付与するよりもたちが悪いです。2

かくして、net use により各ロボット「実行時にファイルアクセス用アカウントを用いたドライブ接続と、処理終了後の切断」という手順をロボットに組み込む必要が出てきます。

net use の使い方と課題

net useの使い方
PS C:\Users\xxx>net use /?
このコマンドの構文は次のとおりです:

NET USE
[devicename | *] [\\computername\sharename[\volume] [password | *]]
        [/USER:[domainname\]username]
        [/USER:[dotted domain name\]username]
        [/USER:[username@dotted domain name]
        [/SMARTCARD]
        [/SAVECRED]
        [/REQUIREINTEGRITY]
        [/REQUIREPRIVACY]
        [/WRITETHROUGH]
        [[/DELETE] | [/PERSISTENT:{YES | NO}]]

NET USE {devicename | *} [password | *] /HOME

NET USE [/PERSISTENT:{YES | NO}]

ロボットの中から実行する場合には Execute CommandLine アクションで net use コマンドを実行します。上記の構文に沿ってコマンド文字列をロボット内で生成・実行するわけですが、以下のような運用上の課題が発生します。

ロボットの処理としてシステムレベルの操作を組み込まなければならない。

  1. CoE が代表して共通処理を作成・配布し、ユーザに利用を促す必要がある。
  2. ユーザによっては共通処理を使用せず独自にカスタマイズする場合があり、ルールが守られない場合ロボット実行時に不明な接続エラーが発生し、情シスが調査に追われることになる。

接続/切断エラーなど、操作が失敗した場合にロボットレイヤーのみではなくOSのレイヤーの対応も必要になる。

  1. エラーによりリモートドライブ接続が解放されない場合、サーバへログインし、net use /delete しないと、その後玉突き的にロボットがエラーとなってしまうこともある。

ロボットの開発者・運用者へファイルアクセス用アカウント情報を教える必要がある。

  1. ロボットに対して付与したアカウント情報をそれ以外の関係者複数で共有してしまうことになる。
  2. 慣れてくると作業ショートカットとして、調査のために自端末から他部署の共有ドライブにアクセスするなどの不適切な行動を誘発する。

可能な限りシステムはシンプルに。

開発・運用もシンプルに保つために、出来るだけ複数のレイヤー(アプリケーション、ミドルウェア、OSなど)にまたがった作業を必要としないアーキテクチャを探求したいところです。

RFSとは

公式ドキュメントの記述は非常に淡白で、いまいちピンとこないので動画で紹介します。
👇

端的に言うと、以下の操作を可能にした機能です。

  • リモート端末(DAS)、ロボット実行サーバーどちらに対しても同じUXで操作可能
  • ファイルへのアクセス認証情報(ID/PW)を MC で一元的に管理し、開発者・運用者が目にすることはない
  • ロボット実行時に自動的にドライブ接続し、ロボット終了時(エラー終了含む)には自動で切断
  • NAS/SANなどのファイルサーバーだけでなく、ローカルの Windows フォルダ、SFTP、および FTP(s) サーバーに対して全て同じUXで接続することが可能
  • ファイルシステムへのアクセス権限は「プロジェクト」「個別のロボット」「特定のバージョンの個別ロボット(パスワードストアと同じレベル)」を選択してピンポイントに付与することも可能

要は、OSレイヤーには関与せず、ロボットのアプリケーションレイヤーで運用が完結する net use の上位互換・次世代機能 です。


:arrow_lower_right:net use の世界
image.png
:arrow_upper_right:RFS の世界
image.png

もっと詳しく知りたい方、実際に環境を構築して使ってみたい方は以下の記事をご覧ください。

まとめ

BizRobo! の機能的特徴として バックグラウンド処理Kapplets というキーワードはよく聞きますが、いまだに ロボット ファイルしシステム(RFS) を挙げる人に会ったことないのは不満です。

もっとアピールすべきだとは思いますね。一利用者としては。

  1. Windowsサーバを前提としています。

  2. ロボット開発者やロボット運用者など、本来ファイルへのアクセス権限を持たないユーザーがロボット実行ユーザアカウントを用いて端末にログインすることによって、許可されていないフォルダに対してアクセスできてしまうことは大きな問題です。

2
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?