はじめに
この10年程で企業(以下、お客様)が利用する業務システムは、クラウドシフト・リフトの流れもあり、多くがクラウド上で稼働するようになってきました。
それに伴い、Microsoft 365、SFDC、G Suite/Google WorkspaceといったSaaS(以下、クラウドサービス)を業務で利用するお客様も更に増大してきています。
クラウドサービスを利用する場合、お客様内からのアクセスは基本インターネットになります。
ただ、クラウドサービスを利用する事で社内資産やシステム運用コストを減らしたいが、扱うデータの種類・内容によっては、セキュリティ観点からインターネットではなく閉域網で接続したいというお客様もまだまだ多いという認識です。
弊社WHIもSaaS型クラウドサービスを提供しています。
私は仕事柄、弊社クラウドサービスへの移行や新規導入の際に、お客様情報システム部門や関連するSIerとネットワーク、セキュリティ、システム運用に関してお話させていただく事が多いため、これまでお話させていただいた多くのお客様とのやり取りから、お客様がクラウドサービスに求めるネットワーク、セキュリティについて整理してみたいと思います。
前提
クラウドサービス側では、WAF、DDos攻撃、IDS/IPS、ふるまい検知、マルウェア・ウィルス対策といった、ネットワークセキュリティ対策は当然の事ながらとられている前提とします。
以下では、クラウドサービスへのアクセス経路、クラウドサービスとお客様保有システム間のデータ連携、クラウドサービスへのデータ移行、取り扱うデータの種類(個人情報や機密情報の有無)の観点での考慮点について考察してみたいと思います。
インターネット経由でクラウドサービスをブラウザ利用する際の考慮点
インターネット経由でクラウドサービスにアクセスする場合、通信はHTTPS(TLS)のみとし、お客様拠点やスマートデバイスなどのクライアント(ブラウザ)から、クラウドサービス宛の通信とするのが大前提になると思います。
当然の事ながら、クラウドサービス側からお客様の内部ネットワーク宛の通信が発生すると、インターネットからの穴を開けなければならないなど、セキュリティリスクが増えるため、これは絶対に避けなければなりません。
ネットワーク制御に関しては以下が考えられます。
1. ネットワーク制御せず、どこからでもインターネットアクセス可能とし、クラウドサービスのID/パスワード認証のみでログイン許可
従業員の退職時などのタイミングで、即座にクラウドサービスのID/パスワードを利用できなくするなどの運用ができればこの方法でもOKとなる場合もありますが、基本的には2または3の対策が必須になるものと思います。
特に、クラウドサービスで扱うデータに個人情報や機密情報が含まれる場合、この方式ではNGになるのがほとんどではないかと思います。
2. ネットワーク制御せず、どこからでもインターネットアクセス可能とし、SAMLなどIDaaSによる認証やMFAにより本人確認した上でログイン許可
個人情報や機密情報を扱わないようなクラウドサービスの場合、IDaaSによる認証やMFAにより本人確認できるようにする事でOKとなる場合があります。
例えばSAMLのIdPとしてEntra IDを利用している場合、条件付きアクセス設定により、お客様拠点や管理端末からの認証はSAML認証のみでOKとするが、私用端末からはSAMLでの認証＋MFAを必須にするなど、IdP側の設定で必要とされるセキュリティ要件に合わせた認証方法とする事ができます。
私の感覚では3～4割位のお客様ではIDaaSを持っているように思いますが、一部従業員がIDaaSのIDを持っていなかったり、システム運用アカウントなど、人に紐づかないアカウントは、IPアドレスで制御しつつIDaaSで認証させないようにするなど、システム運用上の考慮も必要になる点は注意です。
3. お客様拠点など、特定のグローバルIPアドレス(以下、GIP)のみからのみクラウドサービスにアクセスできるよう、クラウドサービス側で設定
インターネットアクセス自体はOKだが、お客様がIDaaSを持っていないなどの理由で、どこからでもインターネットアクセスさせるのはNGな場合、クラウドサービス側でお客様拠点など特定のGIPからのみアクセス可能なよう設定できる事でOKとなる場合があります(認証はクラウドサービスのID/パスワード)。
在宅勤務などしている場合は、一旦VPN等で社内ネットワークに接続し、社内ネットワーク経由でクラウドサービスにアクセスする想定です。
弊社クラウドサービスをご利用のお客様では、特定のGIPからのみアクセス可能にしてインターネット経由でクラウドサービスを利用するパターンが一番多いのではないかと思います。
DX推進やコロナ禍の影響などあり、お客様環境では、自宅などからも含め、Web会議やSaaSへのアクセスはインターネットブレイクアウトさせ、各種SSEサービスと組み合わせてお客様データセンターを経由せず直接インターネット接続させている場合があります。
SSEサービスとして、Zscaler、Prisma Access、Netscopeなどがありますが、サービスによっては接続元GIPを固定できないものがあるため注意です。
お客様セキュリティポリシーでは接続元GIPでクラウドサービスへの接続制御でOKであっても、利用しているSSEサービスによっては実現できない場合があります。
4. お客様拠点のプロキシやFWなどで、クラウドサービスのFQDNまたはGIPにのみHTTPS通信可能なよう制御
何年か前までであれば、お客様拠点からアウトバウンドへのHTTPS通信はAnyで許可されている事もあったのではないかと思いますが、昨今のランサムウェア被害の影響もあり、アウトバウンド通信についても、TLS通信であっても信頼できるFQDNもしくはIPアドレスへの接続を明示的に許可するようになってきています(データが流出しないようにするため)。
アウトバウンド通信の制御をプロキシのホワイトリストなどでFQDN指定で行っている場合はよいのですが、FW等で制御を行う際に宛先をIPアドレスでしか指定できない場合があり、クラウドサービス側でIPアドレスを固定できない場合、注意が必要です。
その他、サービスにより直接インターネット接続させるか社内ネットワーク(VPN)経由にするか切り替える場合にもIPアドレスにより分岐させる場合もあるようです。
クラウドサービス側のIPアドレスを固定にすると、接続元IPアドレス制御する際のIPアドレス(CIDR)数に制限が出たり、コスト増になったりする面もありますが、個人的にはクラウドサービス側のIPアドレスを固定にできるオプションがあると尚よいように思います。
1～4の方法のうち、どれならセキュリティ的にOKかは、クラウドサービスで扱うデータがどのようなものかに依存する部分が大きいと思います。
また、クラウドサービスの中でも機能により個人情報や機密情報を扱うものもあれば、そうでないものもあると思います。
その為、クラウドサービスAは接続元GIP制御が必須、クラウドサービスBは認証と組み合わせた上で、どこからでもインターネットアクセスOKとするなど、サービス毎に制御方法を変えるのはよくある事です。
また、ネットワーク的な話と言うよりアプリケーションよりの話になりますが、接続元GIPなどにより利用できる機能制限をかけられると、個人情報や機密情報を扱う機能は特定のGIPからアクセスがあった場合のみ利用可能にし、その他からのアクセスではセキュリティ的に差し支えない機能のみ利用できるようにするなど、ネットワークとアプリケーション制御を組み合わせる事で、より柔軟な運用が可能になります。
閉域網でクラウドサービスのブラウザ利用が必須である場合の考慮点
クラウドサービス利用はインターネットアクセスが基本ではありますが、金融機関のお客様や地方自治体のお客様などではセキュリティ規定としてインターネットアクセスは一切NGという場合があります。
その場合、インターネットは一切通らず、閉域網でクラウドサービスに接続できる必要があります。
AWS環境にクラウドサービスがある場合、閉域網で接続する方法として以下のような方法があります。
- Direct Connect、Direct Connect Gateway、Transit Gateway、IP-VPN、VPCピアリングなどでクラウドサービスのVPCに直接閉域網で接続
- プライベートリンク経由で接続 ※Azureなどでも同等サービスがある認識
1、2どちらの経路でもインターネットを経由しないという点ではセキュアですが、セキュリティ、コストの観点で以下のようなメリット、デメリットがあると考えます。
| 接続方法 | メリット | デメリット |
|---|---|---|
| Direct Connect等でクラウドサービスVPCに直接接続 | ・インターネットを経由しない通信が可能 ・プライベートリンクより安価に構築が可能 |
・双方向の通信が可能なため、セキュリティグループなどの設定に問題があると、クラウドサービス側で発生したセキュリティ問題がお客様拠点にも影響を及ぼす可能性がある ・クラウドサービス側VPCに接続する手段が複数あるため、お客様毎にクラウドサービス側での対応が必要となり、またIaC化が困難であるためクラウドサービス側の対応コストが大きい |
| プライベートリンク | ・インターネットを経由しない通信が可能 ・お客様VPCからクラウドサービス宛の一方向通信に限定できるため、クラウドサービス側でランサムウェア等の被害があってもお客様拠点では影響を受けない ・HTTPSなど特定のプロトコルに絞った通信が可能 ・エンドポイントポリシーにより細かなアクセス制御が可能 ・クラウドサービス側で個社毎の対応が基本不要になるため、IaC化が可能でクラウドサービス側の対応コストが小さい |
・お客様AWS環境およびお客様AWS環境までをDirect Connect等で接続する必要があり、新規に用意する場合コストが割高になる ・名前解決方法が少し複雑 |
以上から、コスト的にはお客様デメリットがあるものの、インターネット経由NGな場合、セキュリティ的にはプライベートリンクの利用がよいように思います。
システム間データ連携における考慮点
クラウドサービスとのデータ連携は、基本RESTful API(以下、WEB API)を利用しHTTPS通信して行う事になると思います。
クラウドサービス側で考慮しておくべきポイントとして、以下が考えられます。
- データ連携(WEB API)の通信プロトコルはHTTPS
- アクセストークン、APIキー、OAuthなどによるセキュアな認証の仕組みを用意
- データ連携において、通信の起点はお客様環境とし、クラウドサービス側起点でお客様環境宛への通信は一切しない仕様にする(お客様環境からWEB APIを実行し、データをGETしたりPUT(POST)したりする)
- インターネット経由でデータ連携する場合、お客様環境からインターネットに出る際のGIPからのみWEB APIのリクエストを受け付けるよう制御する
- (可能であればアプリケーション側でお客様専用キーを使い)データの暗号化ができるようにする
- インターネット経由でのデータ連携がお客様セキュリティ規定上NGな場合に備え、プライベートリンクなどでインターネット経由でなくてもデータ連携できる方法を用意する
- 可能であればお客様がWEB APIを実装しなくてもデータ連携できるような仕組み(サービス)を用意する
システム間データ連携においては、個人情報、機密情報を含むデータのやり取りが発生する事を考慮し、許可された場所または認証がされないとデータのやり取りができないようにする、データが万が一盗聴されても中身を確認できないようにする、お客様のデータが絶対流出しない仕組み・運用にする事が求められます。
なお、お客様オンプレミス環境で利用していたサービスをクラウドリフトする場合、オンプレミス環境では、FTPやHULFT、SMBなどを利用してシステム間データ連携をしている場合があります。
その場合、既存インターフェースプログラムを大幅に書き換える必要が出てきたり、データ連携経路が変わる事によるセキュリティ対策やコスト負担をどうするかなど別途検討が必要になるため、現行からの変化点を詳しく説明し、役割分担など含めすり合わせをしっかりと行っておく必要があります。
データ移行における考慮点
お客様オンプレミス環境で利用していたサービスをクラウドリフトする場合など、現行環境のデータをクラウドサービス側に移行する必要があります。
データ移行にあたりクラウドサービス側で考慮しておくべきポイントとして、以下が考えられます。
- データ移行時の通信プロトコル(基本HTTPS)
- データ移行ツールを用意しておき、お客様対応の負担を減らす
- 移行ツールはインストール不要で配置できるような形式にし、ネットワーク帯域幅制御できるように(お客様ネットワーク帯域を使い切らないように)しておく
- データ移行用のエンドポイントをクラウドサービス側で用意し、エンドポイントにはお客様オンプレミス環境の現行サービスからのみアクセスを許可する(GIPを限定するなど)
- お客様専用の暗号化キーを使いデータを暗号化する仕組みを用意する(インターネット経由でも安全にデータ移行できるようにするため)
- インターネット経由でのデータ移行がお客様セキュリティ規定上NGな場合に備え、プライベートリンクなどでインターネット経由でなくてもデータ移行できる方法を用意する
- データ移行時に抜け穴となるようなネットワークへの経路を全てふさぐ設計にし、厳密に運用にする
- 現行システムのダウンタイムを極力短く(データ移行にかかる時間を短く)するような対策をする
- 人による作業を極力なくし自動化する
データ移行においても、個人情報、機密情報を含むデータのやり取りが発生する事を考慮し、許可された場所または認証がされないとデータのやり取りができないようにする、データが万が一盗聴されても中身を確認できないようにする、お客様のデータが絶対流出しない仕組み・運用にする事が求められます。
また、データ移行に伴う現行システムのダウンタイムを極力短くする事も大切な要素です。
特に、TBを超えるような大量データの移行方法についても考慮しておくべきポイントになると思います。
おわりに
お客様の情報システム部門の方々がSaaS型クラウドサービスを利用(移行)する際、気にするネットワーク、セキュリティについて、クラウドサービス側で考慮しておくべきポイントについて簡単にまとめてみました。