BizRobo! で内部統制の要件を満たすシステム構成例を紹介します。

はじめに

以前「会社で利用している BizRobo! の運用環境と構成を紹介します」という題名でブログを書いたのですが、出し惜しみ、あまりにもショボい という反応もあり、結局何が言いたいのか微妙な記事という反省もあったので、今回はもう少し実用的な感じで、内部統制の要件を満たすセキュアな運用環境について匿名の事例（脚色あり）を紹介しようと思います。

内部統制の全体像

ロボットをどのように使うかは利用者次第で、全社的な業務から日常的なタスクにまで広く分布しているため一概には言えません。

とはいえ RPA の利用が進み、その範囲を拡大していくと「それって内部統制上大丈夫なんだっけ？」という疑問を投げかけられることがあると思います。

内部統制についてはまず「対象業務やシステム」の範囲が会社ごとに決まっており、それにかかわるプロセスや仕組みに対して一定の水準で統制が取られている（仕組みが存在し、運用されれている）ことが必要という理解です。

よく、業務統制 IT統制 といった感じで分けられますが、今回記述の対象とするのは BizRobo! のシステム構成なので、IT統制 の範囲になります。

一定水準での統制については、専門家ではないので「これ！」と言い切ることはできませんが、重要な要素としては

• アクセスコントロール
• 処理の記録（ログ）

の2つかな？と思っています。BizRobo! のシステム環境構成としては以下のような感じです。

以下、各要素と考え方について簡単に解説していきます。

アクセスコントロール

許可された人以外、触ってはダメ！というコントロールをします。

物理的アクセスコントロール（環境の分割）

BizRobo! Basic では 開発・ステージング環境 用のライセンスと 本番運用環境 用のライセンスの 2 つが一組となっていますので、それぞれのライセンスを利用して物理的に 開発・ステージング環境 と 本番運用環境 の 2 系統を用意します。

ライセンスの機能的な違いとして 開発・ステージング環境 用ライセンスには開発ツール（ Design Studio） へのユーザー認証機能がついていることが挙げられます。本番運用環境 用のライセンスにはありません。

サーバーを 2 台用意するのが困難という理由で 1 つの Management Console に両方のライセンスを設定する場合もありますが、アクセスコントロールの観点からは別々の環境に分けることをお勧めします。¹

システム的アクセスコントロール（アカウント管理）

IT統制においては確か、「開発と運用の分離」が求められていたと思います。言い換えれば 開発者は本番環境にアクセスできてはいけない というもので「プログラムの中身を変更できる者が本番環境を直接操作できる場合、不正なプログラムを無断で本番環境に反映させることもできてしまう」故に 統制が取れていない と詰められます。²

こういった課題へのアプローチとして 認証と認可 に基づくアカウント管理が重要である認識です。

認証 というのは「私怪しいものじゃありません」という 身元 を証明するもので、
認可 というのは「〇〇することを許可されてます」という 権限 を確認するものです。

例えばシステムにログインできるかどうかは 認証 ですが、ログインしたシステム内の何に対してどのような操作ができるかについては 認可により制限されます。

認証

前段のように物理的に環境を分けている場合、開発・ステージング環境 には開発者のアカウントのみを登録し、 本番運用環境 には、システム利用者と運用管理者のアカウントのみを登録することで不要なアクセスを入口で防ぐことができます。

ユーザーによっては 開発・ステージング環境 にも 本番運用環境 にもアカウントを作成したいという場合があります。ただ、2 つの環境ともにアカウントを作成するのは面倒だという理由で環境を併せたり、同じアカウントを流用するのは事故のもとなのでお勧めできません。

今回の事例では登場しませんが、こういった場合には Keycloak などのIAMソリューションとアカウント連携することにより、開発・ステージング環境・本番運用環境 両方のSP（サービスプロバイダ―）にアクセス可能なアカウント情報を一か所で管理できるようになります。

認可

ログインした（認証 を通過した）ユーザーに対して 必要十分 な権限を与えるためにユーザーごとに適切な設定をします。

BizRobo! ではプロジェクトという単位で ユーザーグループ と 権限 を設定することができます。
また、同様に今回の記述の範囲ではありませんが、デフォルトで用意されている 権限 以外のカスタム権限を作成することもでき、より柔軟にユーザーを管理することが可能です。³

処理の記録

リスクへの対応やモニタリングのために、処理の記録は重要です。

システムに対する処理の記録

ロボットの実行ログではなく、BizRobo!の利用者がいつどのように振舞ったのかを監査ログとして収集します。具体的には Management Console を通じて実行した操作を記録します。

• Aさんが YYYY-MM-DD HH:MI:SS に Design Studio を 起動 しました。
• Bさんが YYYY-MM-DD HH:MI:SS に □□ という スケジュールを登録 しました。
• Cさんが YYYY-MM-DD HH:MI:SS に □□ という スケジュールを実行 しました。
• Dさんが YYYY-MM-DD HH:MI:SS に Management Console へ ログイン しました。
• Eさんが YYYY-MM-DD HH:MI:SS に Management Console の ログインパスワードを変更 しました。

監査ログはデフォルトでは有効化されていないので、BizRobo!の構築手順書に沿って設定する必要があります。有効化することにより上記のような情報を収集することが可能になります。

リソースに対するアクセスの記録

ロボットファイルシステム（RFS）⁴ を使用することにより、ロボットが読み書きするファイルについて「いつ」「どのファイル」を「どうしたか」のログを記録することができます。

また RFS を使用することにより、ファイルサーバやアクセス制限のある特定の業務フォルタに対しても、個別に 認証 認可 を実施したうえで特定のロボットに対してのみ（かつ、ロボット実行中に限り）アクセスを許可することも可能です。

その他の管理

今回は BizRobo! の環境について内部統制上どのようにコントロールできるかという IT全般統制 的なことを書いてきましたが、一方で BizRobo! 基盤上で動くロボットが IT業務処理統制 的（？）にコントロール可能であることも重要です。

例えば、BizRobo! が操作する対向システムのアカウントやパスワード（ロボットに付与する認証情報）は安全に管理できるのか？ や、BizRobo!が操作するリソース（ファイルやフォルダ）を外から覗き見られることはないのか？ など。

結論としては Dont't Worry! 専用の機能を持ち、ロボット実行時に利用するパスワード情報などは開発者には一切知らせる必要なく運用することが可能 ですが、詳細についてはまた別の機会に気が向いたら書いてみようと思います。

まとめ

BizRobo! をご利用いただいている各社でそれぞれの取り組みがあると思いますが、今回は私の知っている少ない他社事例の中から幾つかピックアップして、かなり脚色したうえでもポイントがずれないようにまとめてみました。あくまで一例として参考になれば幸いです。

1. せめて同一端末に構築するとしても、コンテキストパスを分けた別アプリケーションとして構築することを検討願います。 ↩

2. 運用管理者が開発プログラムを触ってはいけない。という逆もまた然りですが、実態としては内製の進むRPAにおいては一人情シスで対応せざるを得ないケースもあると思いますし、どうしても一人で両方こなさなければならない状況もあると思います。そんな時にどうルール付けをして対応するか、内部統制システムの導入時に各社工夫を凝らすところだと思います。 ↩

3. デフォルトの権限をカスタマイズするためには Tomcat 内の webapps\mc\WEB-INF\roles.xml を編集する必要があります。編集の方法については機会があれば別途記事にするかもしれませんが、もし編集される場合には十分にご注意ください。（バックアップを取得し、いつでも戻せるように） ↩

4. 図中では Robot File System と記載 ↩