Chapter4-1 三菱UFJのその後、理想と現実

2017年1月に華々しくAWSへの移行をぶち上げ、AWS社のよきリファレンス・カスタマーとして様々な媒体を賑わした三菱UFJファイナンシャルグループだが、その後どのような推移を辿っているか、それほど詳細な情報は出てきていない。断片的な情報はメディアで紹介されてはいるが、企業秘密に属する情報が表にどんどん漏れるようでは、逆に信頼性を失ってしまう、笑。ただし、一部推測を巡らせるに足るような断片情報は、ネット空間にも出てきてはいる。

　2020年の時点で、彼らの目標は移行計画の半分にも満たないと噂されている。AWS移行発表時には、勘定系すらクラウドへ移行するということで大騒ぎになったが、現実はそう簡単ではないようである。勘定系以外に約1000のシステム(おそらくサブシステムも含むのではないか)が存在し、10年間で500システムをクラウドへ移行という触れ込みであった。とするならば既に250システム近くがクラウドへ移行されていなければならないが、大幅に未達のようだ。

　何がその阻害要因となったのだろう。その筋の情報によれば、主要因はクラウドへのデータ移行に伴うセキュリティの担保にあるようだ。しかしながら、そんな事は考えるまでもなく分かりきっていたことであり、だからこそ日本の企業ユーザーはパブリッククラウドへの移行を躊躇していたはずだ。パブリッククラウド事業者との契約書(Term and Condition)を精読したことのある方ならお気づきなのだが、セキュリティとデータ保護については極めて曖昧である。

もちろん彼らも努力はしており、https://aws.amazon.com/jp/compliance/gdpr-center/ にあるように、AWSも多大の投資をしていると思われる。想像するに、契約書上のこの点について、AWS側と三菱UFJ側との間で激しい対立もしくは調整があったのではないか。パブリッククラウドは、基本的にユーザーが事業者にプロセスを合わせろという不遜なスタンスを取っている。従来は顧客の業務やプロセスに合わせてシステム開発を進める（顧客に合わせる）というのが当たり前であったが、パブリッククラウドになれば、いかに日本のメガバンクといえども、世界規模から見ればたかが一行であるからして、特別にコードを書き変えるなり機能を追加するなりは非常に考えにくい。REST APIを使ってユーザーインターフェースを三菱UFJ向けに提供するのとは、その難易度が桁違いに違う。そして、一旦初めてしまえば、三菱UFJが利用する限り、未来永続的にその個別コードをサポート・アップデートし続けなければならない。本来そんなことをしたくないクラウド事業者は、そんな改編を全てのユーザーに提供したくないはずであるし、そんなことをすれば、コストが大幅に上がってしまう。もし実現できたとしても、三菱UFJ向けに取られた特別対応によりコストが上がった分、大きな金銭的負担がライセンス料金としてユーザー側に生じ、レガシーシステムから脱却したメリットが小さくなってしまう。AWS日本法人からすれば、日本市場においては重要な意味を持つ企業であり、大口契約を頂いた顧客だから、本社と顧客との間で大変な思いをしたのは容易に想像できる。

　このセキュリティ問題について、AWS側がそれを自ら解決したのだろうか。「従業員のクラウドの利用状況を確認しやすくしたり、アクセスを制御したりする「CASB（キャスビー）」と呼ばれる仕組みを活用し、不審な通信などを検知できる体制を構築した」とネットでは紹介されているが、これはクラウドの外側で行われた対策であり、AWSの協力は得ているだろうが、クラウドそのもののセキュリティ対策強化とは考えにくい。セキュリティの実装レベルの問題とは別に、ガバナンスの問題がユーザー企業側にあるのは事実だが、このセキュリティの機能実装と企業内ガバナンスというのは表裏一体であり、実現できる機能によって企業統治が影響を受けてしまう。サービス側の問題とクライアント側の過失との切り分けをAWS側で行うのは限界がある。つまり、セキュリティに関しては、ユーザー自身が考えねばならない問題であり、パブリッククラウド側での対応は限定されてしまう。ここにこそクラウドに対するセキュリティ問題の根幹がある。エンドポイントはその典型である。

　BOXの提供している情報をみていると、面白い傾向を見て取ることができる。セキュリティに関する情報が多いのである。まさか、BOXそのものだけでDLP(Data Loss Prevention)を完結できるとは思わないが、堂々とそれをアピールしているのである。つまり、CloudやSaaSベンダーは、自らセキュリティに大きな課題のあることを自覚しているのだ。

【余録】

　またまた余談である。2020年のアメリカ大統領選挙期間において、TwitterをBANされたトランプ大統領が自己発信の場を失い、新しく立ち上がったSNSがParlerであった。個人的には、AWSがParler社のサービスを自身の判断によってネットから切断し、そのシステムリソースとデータを除外してしまったことの方が恐ろしいと感じている。

一般論としてあり得ない、極めて例外的な措置と思いたいが、外部組織の判断一つで企業や組織の活動が死滅してしまう、そんな所に企業や顧客のデータを、私が経営者なら置きたくはない。

 また、一旦AWSへと飲み込まれたデータは、決してオンプレミスへ返さない姿勢を彼らは隠さない。こんな話があった。企業にとってランサムウェアは頭の痛い攻撃である。感染したユーザーに金銭を要求し、支払うまで凍結を解除しない荒手の攻撃に対し、企業の情報システム部門は、バックアップデータをリカバリし、感染していない状態に戻してやる必要がある。そこでバックアップ先としてのAWSと協業という話があった。しかし一方で、DR先からのデータ回復もそうだが、復旧した後に最新のデータをバックアップ先であるAWSからオンプレミスに移動させ、本番稼働をオンプレミスで行いたいユーザーは依然たくさんいる。当時バックアップソフトウェア会社にいた私は、AWSとの協業について、そのシナリオの重要性を説いたが、AWS側は俺様ベンダーよろしく一切を受け付けなかった。全ての企業ユーザーをクラウドファーストにするのが命題と考えているなら理屈は成り立つ。個人的には御免被りたい物である。