日本RPA協会（※1）ではRPAを次のように定義しています。

RPA製品として、当社が提供するWinActorをはじめ、UiPathやPower Automate（Microsoft Flow）などが提供されています。

RPAの利用にあたって、セキュリティ上課題となるようなケースを以下に示します。

例1）.

監査をしていたところ、誰もオフィスにいるはずのない深夜時間帯に業務ファイルの操作があったことが発覚した。情報システム部門では、不正アクセスの可能性があると大騒ぎになったが、あるユーザーが実行しているRPAによるものだと分かった。（野良RPA＝組織として認識されていないRPA）

例2）.

RPAを悪用した不正処理があったことがわかった。しかし、RPAの処理をログなどは残していなかったため、内部犯の特定に至らなかった。（RPAを踏み台とした内部不正）

例3）.

クラウドサービスにアクセスするRPAシナリオを作成した。クラウドサービスのアカウントに自分のアカウントを使っているが、ID・パスワードが、設定ファイルに平文で保存されていた。この設定ファイルはファイルサーバ上にあり、社員は誰でも見られるようになっていた。（無防備なパスワード）

例4）.

発注受付の自動化のためRPAを利用していた。発注処理ではあるアプリを利用していたが、アプリをバージョンアップしたところUIが変更になっていた。RPAはUIの変更に対応できずエラーを起こしていたが、自動実行にしていたため、社員の誰も認識していなかった。発注が処理されていないという、顧客からのクレームで初めて気づいた。（関連アプリバージョンアップによる動作不良）

Gartnerは、解説記事（※2）で「ユーザー部門以外がシナリオ開発を行う企業が8割近い」という調査結果を示しています。RPAに期待されている「業務部門が自ら開発できる」というメリットと相反するようですが、業務での実用に耐えうるRPAのシナリオ開発では、システム開発のスキルが強く要求されると考えられます。

前述のセキュリティリスク例も、システム開発の開発・運用の現場であれば対策が検討されてしかるべきものです。
また、FISCの解説書（※3）では、RPAのセキュリティをガバナンスという観点と紐づけて検討しています。

RPAだからといって特別なセキュリティリスクが存在するわけではありません。RPAのシナリオ開発 ＝ システム開発（の一部）であるととらえセキュリティ対策に取り組めばよいものと考えます。

前述であげたセキュリティ課題例に対する対策を検討してみましょう。（表1）

表1：RPAにおけるセキュリティ課題への対策例

RPAのセキュリティ対策は、システム開発と同様に要件定義や基本設計の段階で検討すべきと考えます。

製品の機能にも依存しますが、RPAは様々な形態での利用が可能です。利用形態により、セキュリティ対策の考え方も異なります。RPAで実現しようとしている処理がどの利用形態かを検討のうえ、セキュリティ対策の取捨選択が必要です。（表2）

表2 利用形態によるセキュリティ対策の違い

RPAだからといって特別なセキュリティリスクがあるわけではありません。ガバナンスが必要なものなのだという認識を持ちつつ、従来のシステム開発・運用と紐づけて、セキュリティ対策を実施することが必要です。

特に見落とされがちな点を以下に例示します。

• アカウント管理（RPAの実行アカウントを、利用者のアカウントとは別に発行）
• ログ出力・ログ点検（不正利用に備えて利用者、処理結果などを記録に残し、定期的に点検）
• ジョブ実行管理（想定通り実行できていない処理がないか、定期的に確認する）
• パッチ管理（RPAからアクセスするアプリやサービスの仕様変更等への対応）
• IT資産管理（野良RPA対策・シャドウIT対策）

など