2024年6月、RPAテクノロジーズ株式会社は、会社統合の上、オープン株式会社へ社名を変更予定です。
 
 
 

BizRobo! ブログRPA関連のお役立ち情報をお届けします

連載企画・RPAセキュリティの最新動向講座 第3回:RPAユーザーのゼロトラスト対応【理論編】

いいね いいね 0
読み込み中...

RPA運用環境をゼロトラスト化する3つのポイント

ネットワークセキュリティの分野における「ゼロトラスト」のコンセプトに関して、いま注目を集めている背景を探った第1回、コンセプトの一般的内容と具体的な取り組みを整理した第2回に続く今回は、特にRPA(ロボティック・プロセス・オートメーション)を導入している企業がゼロトラスト対策を進める上でのポイントについて解説します。

これまで触れてきたとおり、ゼロトラストのコンセプトは、組織内部のデータを守り、もし不正アクセスを受けても被害を抑えられるよう、組織内外で区別することなくあらゆる通信を全て検証し、必要最小限のアクセスだけを認める方法論です。
RPAを利用している、つまりPC上での定型作業をソフトウエアによる自動実行に置き換えている組織では、ゼロトラストに対応することでソフトウエアロボットの不正改造や乗っ取り、アクセス権限の窃取といった脅威を最小化することが可能です。
加えて、より“ありがち”なシナリオとしては、世界的なトレンドとなったゼロトラストが今後、自社のセキュリティ強化策として採用された際には「既存のRPA運用環境を、ゼロトラスト化にあたって要求される条件に適合させる」作業が生じえます。

こうした場面で検討すべき具体的なポイントは、大きく
「認証」「アクセス可能領域の管理」「通信経路の管理」
の3つに大別できます。以下では、これらを順に見ていくことにしましょう。

認証について

ゼロトラストの実現にあたり、組織内のあらゆるITツール・ソリューションが対応を迫られる中でも、とりわけRPAは、固有の事情を抱えています。
というのは、ゼロトラスト化したネットワークでは「誰が」「何をしてよいか」を細かく定め、適切な権限を確認できたときだけアクセスを認める「認証」のプロセスをきわめて重視している一方、RPAには「人がコンピューターで行うあらゆる操作を」「人を直接介在させずに実行できる」という特性があります。
そのため「ゼロトラスト化したネットワークにおいて、RPAを利用したアクセスをどう認証すればよいか、必ずしも明らかでない」という問題があるのです。

連載第1回・第2回でも紹介した、ゼロトラストの“グローバルスタンダード”を示すNIST(米国国立標準技術研究所)の文書「ZERO TRUST ATCHITECTURE」においても、全60ページ近い記述のうち、RPA利用時の認証について触れた内容は、ほぼ以下の1文に限られます。

「ソフトウエアベースのエージェントが、人間の管理者の代わりにポリシーエンジンなどと対話し、どのように自分自身を認証するかは、未解決の問題である」

(出典:「ZERO TRUST ATCHITECTURE邦訳」PwCコンサルティング合同会社)

いかにも心細くなる表現ですが、実際にはRPAツールベンダーやRPAユーザーが長年の実践を通じ、より安全な運用に関する知見を数多く蓄積してきた歴史があります。
それらを総合すると、この“未解決問題”に関する解決の道筋は、既にほぼ確立されていると言ってよいでしょう。

具体的には、タスクを自動実行するソフトウエアロボットを運用中の組織が、それらに関連してゼロトラストに対応した認証の仕組みを確立するためには、
「ロボットをつくる人」「ロボットを動かす人」「動くロボット」
のそれぞれについて認証を行うべきであり、かつ、それで足りると考えられます。
これら認証項目のそれぞれについて、さらに詳しく解説していきましょう。

A. ロボットをつくる人の認証

少なくとも現在の技術水準において、ソフトウエアロボットは、それをつくる人がいて初めて存在し、手を加える人がいない限りは同じ挙動を永久に繰り返します。
ですから、過剰なアクセスやデータ破壊といった攻撃的な振る舞いをするロボットが突如現れたり、それまで平和に稼働していたロボットが密かに不正を働きだしたりしたとすれば、それらは全て、悪意ある「人」の仕業ということになります。

RPAを安全に運用するには「しかるべき権限のある人だけがロボットを生み出すことができ、しかるべき資格のない人には作成はもちろん、修正も認めない」状態が保たれる仕組み、つまり開発権限の認証を通じた、開発環境へのアクセス制限が欠かせません。この点はゼロトラスト対応としてはもちろん、RPA活用それ自体の基本であるともいえます。

B. ロボットを動かす人の認証

一般にRPAの運用方法は、人がソフトウエアロボットを適宜起動させる「アテンド型」と、あらかじめ決められた時間になると自動的に処理が始まる「スケジュール実行型」の2種類に大別でき、多くのRPAツールでは、製品ラインアップやライセンス体系などで、両者を明確に区別しています。

このうちアテンド型のRPAでは、ロボットによる処理中にID・パスワードが要求される場合、ロボットを起動した人が、自身に付与されているものを入力するのが通常です。担当業務を処理する道具としてロボットを利用している実態や、処理結果を目視で確認するなどの責任を負っている点からも、理にかなった方法だといえるでしょう。
このようなケースでは、形式的にも実態としても、「ロボットのアクセス」を「作業者自身によるアクセス」と同視できるので、ゼロトラスト対応として行う認証も、「人」を特定して権限を確かめる一般的な方法をそのまま適用すれば問題ありません。

従って、RPAのユーザー企業が全社的なゼロトラスト対応を進める場合も、運用するロボットがもし全てアテンド型であれば、人を対象とした認証のルールに従うだけで足り、RPAに関連して特別な対策の必要は生じません。

C. 動くロボットの認証

アテンド型と対照的に、所定のタイミングで自動的に処理を始めるスケジュール実行型のロボットは、その挙動を特定の人に結びつけることが困難です。従って、人を対象にした認証のルールを、そのまま用いることはできません。

「営業終了後の基幹システムにアクセスしてデータを取得し、翌日までに集計を終える」用途は典型ですが、スケジュール実行のロボットもアテンド型と同等以上に、ID・パスワードなどでの認証を課されるタスクが頻繁に発生します。
このためスケジュール実行型RPAを運用する組織は、ゼロトラスト対応を進めるにあたり、人を対象とする通常の手法とは異なるかたちで、十分なセキュリティを担保できる認証の仕組みを確立しなくてはなりません。
これを端的に言うならば「スケジュール実行のロボットがタスク遂行に要する認証情報は、そのロボット専用のものとしてあらかじめ取得した上で、所定のタスク以外に流用できない方法、かつ管理者以外は知り得ない形式で保存しておくべき」だということです。

こうした運用を実現するアプローチとしては、機能特化型のID管理ツールを別途導入する方法のほか、パスワード管理機能が充実したRPA製品を選ぶ方法が考えられます。

アクセス可能領域の管理

RPAの開発運用に関する認証をどれだけ厳格にしても、「いったん認証を得られれば、その先で何でもできる」といった状況では、万一悪意ある外部の第三者が認証を突破した場合の被害が拡大するだけでなく、正当な権限を持つ内部者のミスによっても広範囲に影響が及びかねず、また内部不正を誘発することにもなりかねません。

ユーザーがタスクを遂行するために必要な最小限度のアクセスだけを認める「最小権限の原則」は、サイバーセキュリティ全般の一般原則であり、RPAユーザーのゼロトラスト対応においても等しく重要です。具体的には、
※どの開発権限で、どのロボットを改変できるか
※スケジュール実行型のロボットに、システムのどのエリアまでアクセスを許すか
を定めておき、必要最小限の範囲に設定されているか、常時管理する必要があります。

これらを実現する方法としては、ソフトウエアロボット(を起動させた人)からのアクセス要求を受けて認証を行うタイミングで、利用している通信環境などの条件もチェックするようにし、この結果に応じてアクセス可能な範囲が限定される「動的アクセス制御」などが考えられます。

通信経路の管理

ゼロトラストが注目される契機となったトレンドである「リモート環境への移行」に関連して、RPA運用の重要なポイントとなるのが「通信経路の管理」です。

出社して社内設備を利用する場面を主眼としていた従来のネットワークセキュリティでは、社外環境と隔てて内部のデータを守る「境界型防御」のアプローチが主流であり、RPAの開発運用環境や、個別のロボットの設計も、そうした環境を暗黙の前提としている可能性が高いといえます。
従来のRPA運用を、そのままリモートワークにスライドさせようとした場合、「会社の端末でできたことが、自宅のPCからはできない」というケースが、しばしばみられます。これは「端末の通信環境が異なる」という単純な理由にとどまらず、「リモート環境も考慮してセキュリティ体制を強化したのに伴い、組織全体で通信経路が変わった」といった要因が、複合的に関わっている例もあります。

ワークスタイルに合わせて組織のインフラも進化してゆく中で、RPAを従来以上に活用するには、強化されたセキュリティ下での通信経路をあらためて確認した上で、開発環境や運用体制、ロボットの設計等を変更する可能性も念頭に入れておくのが間違いなさそうです。

――――――――――――――――――――――――――――――――――――――――

ここまで挙げた、RPA関連のゼロトラスト対応で検討すべき各点について、では実際のゼロトラスト関連製品やRPAツールはどのような機能を備えており、また運用しているユーザー企業は、それらをどう使いこなしているのでしょうか。連載最終回となる次回は、具体例に則して「RPA×ゼロトラスト」の理想像を探ります。