RPAに組み込むべきセキュリティ対策：Computer Weekly製品ガイド

RPAの利点は人の行動を模倣できる点にある。その原則を念頭に、botによる自動化のセキュリティ対策を講じ、セキュリティの失敗を防止しなければならない。

[Dionisio Zumerle and Cathy Tornbohm，Computer Weekly]

　RPA（ロボティックプロセスオートメーション）ツールはセンシティブなデータを処理することがある。これには口座番号や金額を請求書から決済システムにコピー＆ペーストする作業も含まれる。

　結果として、botは企業のシステムやリソースに対するアクセス権を獲得する。適切なセキュリティ対策を講じなければ、センシティブなデータが攻撃者、特にインサイダーに露呈しかねない。

関連記事

• RPAを使うべき用途、使うべきではない用途
• プロセスマイニングからRPAへ、Siemensの成功事例
• 「事業部門主導のRPA導入」に多い勘違い
• 6.6億円のコストを削減した、RPA導入成功の秘訣
• IT部門主導のRPA導入を成功させる不可欠な要素

　例えばbotの認証情報やbotが扱う顧客データが露呈する恐れがある。インサイダーがRPAのアクセス権限を悪用して、実行されるRPAスクリプトに不正行為を挿入することも可能だ。従って、セキュリティを含む適切なガバナンスは欠かせない。

　セキュリティ担当者は、RPAを単なるスクリプトの記録・起動ツールとしてではなく、ビジネスプロセスオートメーションに対するアプローチとして扱う必要がある。いったん導入されたRPAは、社内インフラの一部として統合される。セキュリティ対策も同様に統合する必要がある。

監査証跡

　RPAのセキュリティ対策は、サードパーティーツール経由では提供できない、あるいは提供すべきではないものもある。サードパーティーの監査ツールを利用することは可能だが、RPAツール自体がログを生成する必要がある。これにより、RPAツールがアクセスしたアプリケーションで行った動作を完全に可視化できる。他のツールでは、可視化できないあるいはアプリケーションとの互換性がないといったギャップが生じる恐れがある。

　RPAのログ、つまり監査証跡は、否認防止を保証するためには不可欠だ。これがなければ捜査することはできない。RPAツールはその動作について、システムが生成する完全かつ改ざん不可能なログを提供できなければならない。

　一般的に、RPAのログは別のシステムにフィードする。ログはそのシステム上で安全かつフォレンジック捜査に耐えられる状態で保存される。ログは完全でなければならない。隙間があれば捜査の妨げとなる。セキュリティチームが重要な痕跡を見落とすこともある。

　ログはシステムが生成するものでなければならず、改ざんできないことを保証して完全性が守られなければならない。そのための方法の一つにログへの署名がある。スクリプトの完全性を保証するため、ログでは開発者などの関係者がスクリプトに加える変更についても考慮する必要がある。

人間の認証情報をbotに使い回さない

　botオペレーターは、RPAスクリプトを起動して例外に対応する従業員を指す。

　だがRPAの導入を急いで即座に結果を求める中で、botオペレーターとbotそのものの区別がつかなくなることもある。そうしたbotは人間のオペレーターの認証情報を使って運用されている。

　これでは、botがスクリプトで指定された業務を行ったときと、人間のオペレーターが作業したときの区別がはっきりしなくなる。それが原因で、動作や過ち、そして最も大切なことに、攻撃や詐欺行為の責任を特定することが不可能になる。

　人間のオペレーターの認証情報をbotに使い回すことに伴うもう一つの問題は、管理者がパスコードの複雑性や入れ替えの頻度を最低限に抑えがちな点にある。

　管理者が考えるのは、botが何を処理できるかではなく、合理的な人間のユーザーエクスペリエンスとは何なのかに限定される。そうした状況は簡単にブルートフォース攻撃を招きかねず、結果としてデータ流出につながる。

　Gartnerは、各botに個別のIDを付与することを推奨する。botには可能な限り専用の識別認証情報を与える必要がある。

　命名基準を確立すれば、人間とbotのIDを区別できる。これだけやっておけばそれを正しく実行に移せるという方法は存在しない。一例として、「E-123」というIDを持った従業員が運用するbotには「B-123」の識別番号を割り当てるというやり方もある。

　究極的には、E-123というユーザーがB-123というbotにXという仕事をやらせたという情報が監査証跡（ログ）に記録される必要がある。

　このルールが当てはまらない用例もある（例えばコールセンターのオペレーターなど）。その場合、人間のユーザーがRPAを自分のコンピュータで利用して、もっと規模が大きい手作業プロセスの一部である特定業務を自動化する。

　これはロボティックデスクトップオートメーション（RDA）と呼ばれることもある。こうした場合、ユーザー認証情報の使い回しを避けるのは難しいかもしれない。

RPAデータアクセスの厳格化

　RPAにデータベースを直接操作させることに不安を感じる組織もある。これがデータ改ざんを招くこともあり得るが、最も重大なのはデータ破損につながることだ。

　データベースにアクセスするためのユーザーインタフェースが利用できる場面では、たとえそれがbotを減速させることになったとしても、活用する必要がある。あるいは、データベース挙動モニターのようなツールをデータベースの前に配置してモニターに使うこともできる。

　ほとんどのRPAツールは、アクセスを制限する役割ベースとリソースベースのアクセスコントロール機能を搭載している。RPAツールをディレクトリサービスと連携させてリソースへのアクセスを制限し、適切なアカウント権限を割り当てるやり方もある。

　GartnerはIT部門に対し、RPAツールの無料版で本番用のデータを扱わないよう助言している。無料のRPAツールはトライアルのみを目的としていて、セキュリティ機能を伴わないこともある。そうした無料版で扱ったデータは公にされる可能性がある。必ずテスト用のデータを使ってトライアルのみの目的で使用しなければならない。

　Gartnerはセキュリティ担当者に対し、RPAアクセスを厳格に制限して各botが割り当てられた仕事を行うために必要なものにしかアクセスできないようにすることを提言している。一例として、データベースから特定の値のみをコピーして電子メールにペーストするRPAスクリプトなどが挙げられる。

　そのスクリプトを処理するbotに与えるのは、データベースに対する読み取り権限のみとしなければならず、書き込み権限を与えてはいけない。

事業部

　ほとんどのRPAプロジェクトは事業部が主導する。ITチームとセキュリティチームが開発過程で相談を受けることがあったとしても、散発的なものにすぎない。プロジェクトは事業部によって運営され、後にどこかの時点でIT部門に引き渡されることがあるかもしれない。

　セキュリティチームとRPAプロジェクトを率いる事業部との間で、共通の言語と継続的な対話を確立することは不可欠になる。これには各RPAスクリプトについてリスク評価を行うリスクフレームワークの確立も含まれるかもしれない。

本稿はGartnerのアナリスト、ディオニシオ・ズメール氏とキャシー・トーンボーン氏による「Top four security failures in robotic process automation」より抜粋。