Blue Prismベストプラクティス 設計編 5 内部統制対応
「ジャナイホー」による「ベストプラクティス」シリーズ、今回は、設計編5 内部統制対応 です。
RPAという言葉を生み出したBlue Prismは、コンプライアンスの厳しい金融業界のお客様に育てられて、長い時間と工数をかけてから、市場に展開されました。そこで培った経験とアーキテクチャが実現する、内部統制対応のいくつかの機構を是非、実装してみましょう。
内部統制に関しては、Blue Prism Portalに下記文書もありますが、この内容とロボットの実装について、一部補足をしながら、説明していきます。
v6 Data Sheet - PCI DSS Compliance (Log in | Blue Prism Portal)
（※ごめんなさい、本文書はBPご購入済みの方、パートナー様しかアクセスできません。）
Blue Prismが持つ、内部統制関連の機能
Blue Prismが持つ、内部統制関連の機能は、以下があります。（今回の記事では、各機能の説明は割愛します。）
・ コントロールルームでのロボットの一元管理（プロセスの作成、実行、スケジュール、監視、制御）
・ セキュリティ管理（認証情報の一元管理、パスワードの自動生成関数）
・ プロセス、オブジェクト修正履歴の管理、新旧履歴の比較
・ セキュアなDBでの監査証跡、実行ログの一元管理（管理者権限を持つユーザだけでなく、一般ユーザ含めた全ユーザのログイン履歴や設定変更履歴の管理）
・ 詳細なアクセス権限管理（v6.3以降の複数チーム環境によるオブジェクトレベルの高度な権限管理）
内部統制関連の開発ベストプラクティス
これらに加えて、内部統制上の観点で、ロボットに実装するべきことやソリューション設計時の考慮事項としては、以下があります。
認証情報、機密情報セキュリティ管理
・ 認証情報の格納・入手方法（アクセスするアプリケーションへログインする際に利用するユーザIDやパスワードを、BPのセキュアな領域に格納するか、それとも、他のDBなどから入手するか、決める）
・ センシティブなデータのマスキング（ログやWork Queueに値が露出しないような実装規約にする）
・ センシティブなデータの値の入手・利用のタイミング（極力「ジャストインタイム」で利用する実装を心掛ける）
・ ステージロギングのDisable/Enableポリシー（規約に基準を明記する）
・ Work Queueの暗号化（Queueのデータにセンシティブなデータが含まれる場合の事前設定）
・ アプリケーションへログインするパスワードの定期的な変更（BPで自動的に行う実装を作る。※これについては、別の機会で説明していきます。）
データ保持期間とパージ運用
また、以下のような点についても、RPA導入プロジェクトにおいては、考慮しておく必要があります。
・ Work Queue Itemを定期的に削除するプロセスの作成と実装
・ セッションログのアーカイブポリシーとアーカイブスケジュール設定
・ ロボットが処理を開始するトリガーとなるインプット（作業指示）ファイルの待避、削除
・ ロボットがアウトプット出力するレポート・帳票ファイル等の削除
単純にハードウェアリソースの見積で考慮するだけではなく、監査部門からの要求、組織で決められたデータ保持期間のポリシーなどとを照らし合わせて、策定し、規約文書に明記していく必要があります。
少しずつ、見ていきましょう。
認証情報の入手方法
アクセスするアプリケーションへログインする際に利用するユーザIDやパスワードを、セキュアな領域に格納するようにしましょう。そしてロボットが実行時に適切にそのデータを抽出して、アプリケーションへログインできるように実装します。プロセスやオブジェクト内にユーザID、パスワードをハードコードしておくような実装は回避します。（他のDBなどから都度抽出する必要があれば、その仕組みを利用した実装とします。）
「Blue Prismのセキュアな領域」とは、以下の場所になります。
そして、ここに格納された認証情報にアクセスするには、以下のオブジェクトを使います。
Internal Business Object – Credentials - Get
これを実行すると、出力パラメータに定義されたユーザID、パスワードのデータアイテムに、先に設定した認証情報が格納されます。このサンプルは、先に説明したプロセステンプレートにも含まれていますので、参考にしてみて下さい。
センシティブなデータのログへの露出
顧客データの氏名、クレジットカードのカード番号などを扱う場合、これら非常にセンシティブに扱わなくてはならないデータがログに露出してしまうことを回避する必要があります。これには先ず、こういったセンシティブなデータについては、Password型のデータアイテムを利用します。
皆さん既に、アプリケーションへのログインする際のパスワードなどについては、Password型のデータアイテムを利用されていると思いますが、マスキングしたいデータについても、これを利用しましょう。
もちろん、SubページやオブジェクトのInput/Outputのパラメータも、忘れずにPassword型で渡すようにしておきます。
これにより、万が一、ログにデータが露出してしまう場合でも、マスキングされた状態となりますので、漏洩のリスクを回避できます。
そして、センシティブなデータを扱うステージやアクションが多ければ多いほど、ログに露出してしまうリスクも高まります。センシティブなデータの値の入手・利用のタイミングに注意し、極力「ジャストインタイム」で利用する実装を心掛けましょう。
つまり、例えば、
1. 画面入出力が発生する直前で、セキュアなデータストアからカード情報をBP上に取得し、
2. そのステージ直後でデータアイテムをNULLクリアする、
など、極力Blue Prismのプロセスの中で保持される時間、ステップを最小にするように設計・実装します。
各ステージのログ出力Enabledフラグを操作することで、ログに情報を出力しないようにすることは可能です。ただこれをロボット開発者の実装に依存したままにしておくのはリスクがありますので、先ずは
1. センシティブなデータを扱うステージについては、ログをDisabledにする旨、規約に明記する
2. ログ出力レベルを管理者が管理する
ということを徹底します。
ですので、プロセスやオブジェクトを開発者以外の人間がレビューする、ということが非常に重要になります。
PCI DSSに対応しなくてはならない、というような要件がある場合では、RPAの機能面やセキュリティ設定だけでなく、このレビュー体制も含め、きっちりと明文化、運用していくことが必要となります。
運用モデル全体の設計が重要、ということになります。Blue PrismのROM（Robotic Operating Model）という運用モデルについては、別の機会でご説明していきます。
Work Queueの暗号化
Work Queue Itemに個人情報などセンシティブなデータを書き込んだ場合、それは、Blue Prismのデータベースサーバのテーブルに書き込まれます。そしてこれは、QueueのItemを削除しない限り、永続的にデータベース上に保持されますので、注意が必要です。（組織のセキュリティポリシーに依って、例えば、個別のデータベースや特殊なセグメントに分けて格納する必要が発生するケースもあります。）
ですので、Blue Prism開発ベストプラクティスにおいては、センシティブなデータについては、先のマスキングに加え、
1. Work Queueを暗号化する
2. Work Queue（特にKey項目）にセンシティブなデータを書き込むことを回避する
を推奨しています。
暗号化アルゴリズムとキーについて
Blue Prismにおいて、Work Queueを暗号化するアルゴリズムは以下の3つから選択可能です。(v6.3時点)
・ AES-256 AesCryptoService (256 bit)
・ AES-256 RijndaelManaged (256 bit)
・ Triple DES (192 bit) ※後方互換の為だけに用意されているもので、非推奨です。
このうち、「AES-256 RijndaelManaged」がもっともセキュアだと言われています。
暗号化キーは、通常は基本、アプリケーションサーバで稼働する、Blue Prismサービスプログラム（BPServer.exe）にて、保持・管理されます。この為、暗号化キーが不正に入手されないよう、アプリケーションサーバで稼働するBlue Prismサービスプログラムへのアクセス権限を厳重に監査・管理することが必要となります。（運用開始後は、通常、どんなユーザも当該プログラムへのアクセスは不要、な、はず、、、です。。。）
これとは別に、システム管理画面にアクセス権があるユーザは、Work Queueに対する暗号化設定の実施有無の選択オプション（先の画面ですね）を操作することが可能です。
但し、例えば、暗号化オプションをオンにした状態で、本番運用開始して、ItemがAddされたり処理された後、悪意を持ったユーザが、このオプションフラグをオフにしたとしても、その時点まで登録・処理済みのItemについては、復号化はされません。（その時点以降で追加・処理されたItemが「暗号化されない状態で」DBに格納される、ことになります。）
よって、一度暗号化されてDBに保持されたものについて、復号化は、暗号化キーを入手しない限り、基本的には、誰も出来ないということになります。
処理済みのWork Queue Itemを再実行したり、そのWork Queueにアクセスし、格納されているセンシティブなデータにアクセスするような、不正なプロセス・オブジェクトを作成、実行することは可能ですが、それらの所業・操作はすべて、セッションログや監査ログ上に残ります。
コントロールルームやシステム管理画面へのアクセス権限設定を適切に行うことが肝要です。
Work Queue Itemの削除
センシティブなデータを含んでいるか、いないかに関わらず、Work Queue Itemを削除することを考慮する必要があります。
Work QueueのItemはそのまま残すことも可能ですが、溜まる一方ですので、データベースのテーブル・ディスク領域をいずれは逼迫する恐れもあります。よって、定期的にItemを削除（パージ）する運用を推奨しています。
この場合、Work Queue Itemについては、削除するプロセスを構築・実装する必要があります。（セッションログについては、アーカイブ機能があり、システム管理画面から行えます。）
削除するタイミングや頻度は、組織の監査ポリシー（データ保持期間）とディスクスペース等リソースとの兼ね合いで検討して下さい。
データベースサーバに対して、Delete文を発行するなどのスクリプトで定期運用することも可能ですが、Blue Prismのプロセスで構築・運用することにより、Blue Prism上に監査ログやセッションログとして、誰にも改ざんすることができない記録がきちんと残ります。
まとめ
ここに挙げたような、ログの保存やパージ、認証情報、機密情報セキュリティなどについては、手作業で行き当たりばったりで保守したり、開発者任せにするのではなく、しっかりと設計し、実装ポリシーを決め、ポリシーに沿って運用することが、セキュアなロボット構築と内部統制にきちんと対応したエンタープライズRPAの実装に繋がります。
また、
誰が、いつ、何に対して、何を行ったのか。どんな情報を扱ったのか。
こういった記録が、誰にも改ざんすることができない、セキュアな領域に、一元管理されていること。
これが、PCI DSSに限らず、内部統制上、非常に重要なポイントです。
Blue Prismは、これを実現する機能と方法を提供します。実際に実績もあります。
さて、次回、そもそも、この自動化しようとしている案件って、RPAに向いているんだっけ？ 向き不向きってどんなこと？ こんなことを考えてみたいと思います。
※本投稿は、別ブログで掲載・公開していた内容に加筆・修正を加え再掲載しています。