NTT DATA

DATA INSIGHT

NTTデータの「知見」と「先見」を社会へ届けるメディア

絞り込み検索
キーワードで探す
カテゴリで探す
サービスで探す
業種で探す
トピックで探す
キーワードで探す
カテゴリで探す
サービスで探す
業種で探す
トピックで探す
2020年11月13日技術ブログ

MuleSoftを用いたiPaaS導入時の実践的設計テクニック

国内でも近年導入が進むiPaaS(integration Platform as a Service)はその実力にも関わらず、クラウドサービスであるがためにセキュリティ面や運用面での懸念から導入を敬遠されるケースがある。
本稿では、現在国内で最も勢いのある製品の一つであるMuleSoftをピックアップし、導入を妨げるポイントを解消するための設計例を紹介する。

近年、DX(デジタルトランスフォーメーション)の一つの手段として、SaaSやトレンド技術を用いて構築したデジタルシステムと、オンプレミス環境に見られるようなレガシ―システムとを連携させることでデータ活用を進めることのできるiPaaS(integration Platform as a Service)が注目されています。(※1)
iPaaSはデータ連携を行うアプリケーションの開発から運用までに必要となる機能をクラウドサービスとしてワンストップで提供しており、様々なメリットを持っています。一方で、クラウド上にあることからセキュリティ面や運用面に懸念を持たれてしまい、実導入に至らないケースもあります。そこで、本稿ではiPaaS導入の際にノックアウトファクタと誤解されるようなポイントをクリアするための設計テクニックを、MuleSoftを用いてご紹介します。

(※1)こちらの記事でも紹介しておりますのでご参照ください。
「既存IT資産を有効活用するためのAPI戦略 ~NTTデータのiPaaSへの取り組み~」

https://www.nttdata.com/jp/ja/data-insight/2020/0306/

1.iPaaSのアーキテクチャ

まず、本題の前にiPaaSのアーキテクチャを紹介します。

図1:iPaaSのアーキテクチャ

図1:iPaaSのアーキテクチャ

図の左側は、データ連携処理を行うアプリケーションが実際に動き、クライアントからのAPIコールに対する制御が行われる実行環境です。右側の管理環境は、アプリケーションの実装・テスト・実行環境へのデプロイや、実行中のアプリケーションをモニタリング・監視する等の運用機能を持ちます。そして、この実行環境/管理環境ともに、iPaaS製品ベンダが運用・管理するPaaS/SaaSの形で利用者に提供されます。厳密には、製品によって、オンプレミス環境上に実行環境や管理環境を自ら構築するオプションも選択可能ではありますが、本稿では一番オーソドックスと言えるこのアーキテクチャを前提に話をします。

2.iPaaSの課題

前章で紹介したアーキテクチャを実際の開発現場に当てはめると以下の図のようになります。

図2:iPaaSのシステム配置

図2:iPaaSのシステム配置

この例ではインターネット上にあるシステム(図の左側)とオンプレミス環境上のシステム(図の右側)とをiPaaSを介して連携させるケースを表しています。では、このケースではどのようなポイントがiPaaS導入を阻む要因となりうるでしょうか。
幾つか挙がるかもしれませんが、本稿では管理環境部分でよくあるケースについてご紹介します。この図からわかるように、実行環境が本番用と試験用で分かれて配置されているのに対して、管理環境は一つです。システム開発の現場では、開発中の資材が本番環境にデプロイされてしまうといったオペミス防止の観点や開発ベンダによる本番環境への不正アクセス・不正操作防止の観点から、本番用と試験用で環境を明確に分離することが要件として求められるケースが多くあります。しかし、MuleSoftでは管理環境がURLレベルで物理的に分かれたテナントとして提供されず(※2)、かつ、ユーザが実行環境にアクセスするための通信経路上に管理環境が位置することから、管理環境のテナントが一つであることがセキュリティの課題として認識されることがあります。

(※2)

基本ソフトウェアライセンスを追加で購入するとテナントを分けることも可能ですが、ベースサブスクリプションのライセンス料金が追加で発生するため、管理環境は1つとなるケースが一般的です。

3.課題に対するアプローチ

このような課題は以下のような大きく分けて2つの設計で解消可能です。
一点目はMuleSoftのユーザ権限設計です。MuleSoftでは機能/操作対象環境/操作内容(READ/EDIT/DELETE)単位に柔軟に権限設定が可能です。ここでは本番環境用権限と試験環境用権限を別々に作成し、各ユーザアカウントにはどちらか一方の権限のみを付与するよう設定します(本番用ユーザと試験用ユーザを作成します)。これにより、例えば、試験環境への操作権限しか持たないユーザが誤って本番環境へアクセスするようなオペミスを防ぎます。ただし、これだけでは、権限のないユーザが本番用ユーザになりすまして不正操作を行うといった行為は防げません。そこでもう一点対処が必要になります。

二点目は管理環境へのユーザログイン認証設定です。ログイン認証に多要素認証や接続元IP制限を用いることで本番環境への操作権限を持たないユーザが、IDを不正に入手し、自宅や開発端末から本番環境へアクセスするといった不正操作を防止することができます。なお、2020年9月まではMuleSoftではID/パスワードによるベーシックな認証機能しか持たず、外部の認証プロバイダと連携させる必要がありましたが、2020年10月の製品アップデートから多要素認証が可能となったためMuleSoft単体で課題が解消できるようになりました。

上記のような2つの対処を行い、権限設計による論理的な分割と、認証機能を用いたアクセス元ネットワークの分割を組み合わせることで、物理的に分かれていない管理環境テナントを実質的に分離することができます。

4.おわりに

本稿ではMuleSoftを用いてセキュリティ課題に対する設計テクニックの一例を記載しました。現場では他にも大小様々な課題が生じることと思いますが、このような一工夫で解消するものもありますので導入検討時の参考になれば幸いです。また、NTTデータではMuleSoftに限らず複数のiPaaSの製品検証、導入支援を積極的に行っています。このような取り組みを進めることで、iPaaSを普及・発展させ、最終的にお客様に対して高い価値を提供できるよう努めてまいります。

お問い合わせ