クラウドサービス契約上のポイントを解説していただいた




シンジです。ITリーダー向け専門メディア(自称)の記事で、「その契約内容で本当に大丈夫ですか?導入企業が必ず注意しておきたいクラウドサービス契約上のポイント」の内容について一部で話題になったので読んでみたら、なかなか面白かったので感想文です。

その記事はこちら

その契約内容で本当に大丈夫ですか?導入企業が必ず注意しておきたいクラウドサービス契約上のポイント
https://enterprisezine.jp/article/detail/10863

クラウドサービス提供者の契約書を読めってことだそうだ

記事では、「基本契約」と「SLA」があるから、それを前提にしつつ、自社の都合に合わせて個別契約をして契約内容をカスタマイズせよとのこと。サービス提供者側と、しっかり交渉せよとのこと。

まぁ、そんなのやらねーから。
常識的に考えて。

ENISAのガイドラインを使うといいぞってことらしい

具体的に挙げると多いので、ポイントいくつか紹介しています。

クラウドサービスの終了または障害

記事では、一般的には3ヶ月前告知でサービス終了なので、個別に交渉して半年から1年に交渉せよとのこと。

まぁ、そんなのやらねーから。
常識的に考えて。

司法権の違いから来るリスク

海外にサーバを置くときは、海外の裁判所で争うことになるから、日本の法律に合わせた契約書を作って組み込むべしとのこと。

まぁ、そんなのやらねーから。
常識的に考えて。

他の共同利用者の行為による信頼の喪失

サービス丸ごと落ちたときに、自社も使えなくて損害出るだろうから、負担限度額を交渉せよとのこと。

まぁ、そんなのやらねーから。
常識的に考えて。

ロックイン

クラウドサービスに移行すると、自社のノウハウが失われて、値上げ時や撤退時に大きな影響を受けるリスクになるとのこと。

自社のノウハウが失われるとはなんなのか。

証拠提出命令と電子的証拠開示

サーバが物理的にFBIとかに押収されたら、自社の情報も持って行かれるかもしれないし、国際間の政治問題も考えると、リスクだそうで。

何と戦ってるのかな?

フォローしておくと

記事では契約にフォーカスして書かれていて、その時に契約担当者がどのように判断したら良いのかを文字に起こしているんだと思うので、あながち間違ってはいないのですが、間違ってます。フォローになってねぇ。

参考にしてるENISAのガイドラインが2009年版

みなさん2009年の時に使ってたパソコンとかスマホってなんですかね。どんなアプリ使ってました?その時に書かれた文章だということは、その元ネタが完成したのは更に4〜5年前ってことです。

ISO27001(ISMS)はセキュリティ監査の中でも名前が知られてると思いますが、最近ちょいちょい取る会社が増えてきたISO27017(ISMSを拡張してクラウドもフォーカスしたやつ)ですら、世の中にお披露目されるまでに何年もかかってるわけです。

未来を作るITエンジニア諸君が、これほどまでに古い考え方で作られたものに縛られて未来を作れと言われているわけです。まぁ、そんなのやらねーから。常識的に考えて。

現実解はこうします

クラウドサービスを自社で導入する場合、どの様な検討を行って導入に至ったか、これをエビデンスとして記録しておくことで監査で使えるわけですが、まぁそんなの後からいくらでも用意できますからね。国際監査がこれで通せるんだから、所詮はその程度のものってことです。

何故なら、どのクラウドサービスが「良い」のか「悪い」のかなんて、究極的には誰にも分からないし、その時に自社で必要だった物を買っただけの話であって、現実的には後回しです。

ただ、事実として、シンジは過去に受けてきた数多くの監査に対応するために、自社導入するクラウドサービスの評価シートをそれっぽく作成して、そのお陰で、どの辺りを見ると「まともそうな」クラウドサービスなのかを感じ取ることは出来るようになりました。

超有名どころのクラウドサービスはおいといて、ポッと出のクラウドサービスなんて、ごまんとあるわけです。今はそーゆー時代です。誰でも提供者側に回れるわけです。

わけの分からんクラウドサービス業者に、自社の情報を預けるなんてもってのほかだ!と言いたい気持ちはよく分かりますが、そもそもわけが分かってるクラウドサービス業者がいるなら、そこがどうしてわけが分かってると言えるのか説明してもらいましょう。

と言ってみたものの、そんな面倒な会話なんてしたくもないですね。

リスクの定義

リスクという単語、みなさんはどんな場面で、どんな状況の時に使ってますか?

リスクという単語には個人的な経験値や、過去の経緯、政治的な問題などが絡んで、各個人の中でのリスクの定義はかなり曖昧です。そこで、監査上ではあいまいな表現は不都合なので、金融庁の場合は「半年以内に会社が傾くとか潰れるとかそーゆーのをリスクって言うわ」ってな具合で決めてるんですね。

じゃあ社内の人たちや取引先の人たちがリスクと発言したときに、それは半年後の〜なんて考えをめぐらせることなんてないですよね。リスクっていうのは、危ないとか、不安とかをまるっと表現しただけの個人的感情にしか過ぎないものであって、会社や組織としてのリスク評価をクラウドサービスに当てはめるのは、ただの上っ面、もしくは言い訳でしかないと思ってますよ。

シンジはクラウドサービスをどう評価しているか

記事では、会社の都合に合わせて相手に押しつけろと言わんばかりの内容でしたが、国そのものが動くくらいの大きな利益を相手が感じられるような契約書を用意できないなら、ただの外野ですよ。寝言は寝て言えです。

契約面で重視するのは、セキュリティ、サポートレスポンス、ロックインだけです。

まずセキュリティ評価は、外から見るだけなので限界があって、どれだけ外部監査を受けてるか、ドキュメントが揃ってるか程度しか見られません。後は買って使って考えます。必要な場面で暗号化されているか、監査ログは取れているか、APIの更新頻度や内容はどうなってるか。いろいろ見ますが、実運用を鑑みた現実的なラインで見ます。ガイドラインに書いてあるからそこをチェックしようとかやってる時点で、一生エクセル開いてろって感じですわ。

サポートレスポンスは、もはや買わないと分からないです。どんな手段で連絡が出来るのか、どんな人がどんな感じで返答してくるのか、土日に送ってみたらどれくらいのラグで返事が来るか、そもそもどの国から返事が来るかなどなどを見ています。

もはや感性の問題です。
サポート担当者だって、こっちを助けたいんです。こっちだって困ってるんです。契約書通りに仕事しろやおら!なんて言わないです。だって相手も人間ですよ。

ロックインについては、契約にフォーカスすると、どのタイミングで解約できるかを見ています。SaaSだと月額だと割高だけど、年額にすると安くなるよみたいなのが多めです。大手クラウドベンダーのように、使った分だけ課金されて、使わなければ請求が発生しないってケースもありますが、ごく僅かです。

シンジの場合、テスト的に使ってみようってノリでも、速攻で買うので、必ず月額契約かつ最小限のユーザー課金などで済む範囲に留められるように選んでいます。逆に年額しかないものは基本的に「強気」のサービスなので、それはそれで信用度が高まったりもします。

訳分からんスタートアップのサービスが年額契約だったら、そっ閉じですわ。

クラウドの良いところは、小さく始めて、捨てられるところなので、それが出来ないクラウドサービス提供者は、そもそもクラウドの良さが分かってないと考えているので、切り捨てます。

他にもいくつか見ますがだいたいこんな具合です。

実は評価を一部自動化できたりもします

CASBで有名なNetskopeを契約している人たちはご存じかと思いますが、Netskopeのサービス内にCloud Confidence Indexというサービスがあって、Netskopeがクソ面倒くさいクラウドサービスの外部評価をやってくれて、数値で分かりやすくしてくれるんです。

画像は一例ですが、中身は定期的に更新されていて、点数も変わります。過去はどうだったかの記録も見られます。提供会社の事業継続性や、ユーザのプライバシー保護など、監査ポイントは多岐にわたります。

SlackとChatWorkを比較してみます

比較した時にどこに違いがあるのか分かりやすく表示されます。暗号化はどうなっとんねんとか、監査ログはどこまで取れてんねんとか、こりゃ便利です。

点数が低いから採用しない、というのは無い

契約書に目を通すのはとても大事な事です。その昔、Wantedly Peopleという名刺管理サービスがリリースされたその日に、公開されていた契約文面に目を通したら、違和感を感じるところがあって、それを1週間後くらいに暇つぶしでブログに書いたら騒ぎになりました。当時の規約だけ見ると、まるで名刺のデータが自分の知らないところで利用されるような感覚を受ける記述があったわけです。

Wantedly Peopleで読み込んだ名刺データ、誰のものになる?
http://blog.animereview.jp/wantedly-people-privacy/

じゃあ実際にサービス提供側がそういったことをしてるかというと、そんなことは無かったわけです。彼らは純水にテクノロジーを駆使して名刺管理を効率よく行うためにはどうしたら良いかを議論していたし、ユーザの為にそれを解放しただけであって、世の中をもっと良くしたい、便利にしたいという思いがしっかりと詰まってるサービスだったことが分かったわけです。

Wantedly Peopleについて、Wantedlyに行って聞いてきた
https://blog.animereview.jp/wantedly-people-info/

このケースでは、たまたま規約が変な感じになってて、たまたまシンジが指摘して、マジで悪意も何も無いから速攻で修正したってケースなんですが、まぁこんなケースはマレです。

お互いに合意できるのは、「自分たちがもっと便利で、良い環境を手に入れて、もっと成長したい」って思いが双方にあるかどうかってだけです。先程のNetskopeのCCI比較画像を見ると、点数が比較しやすいので、まるでSlackが優れていて、ChatWorkが劣っているように見えます。が、重要なのはそこではなくて、どんな手段を使ったら自分が、自分たちが、同僚が、組織が、会社がもっと良くなるのかってことを考えた結果、そのクラウドサービスを選んだってところなんです。

リスクは排除しなくていい

サービス提供側だって、神様じゃないので、ユーザーからのフィードバックがあって改善されたり新機能が出来たり。オープンソースプラットフォームがまさにそれですよね。お金を払って買っているからと言ったって、相手にも都合と限界があります。人間なので。

リスクだけに限りません。
「知らない」と、「分からない」の差はでかいんです。

その上で、「分かっている」になると更に差が開きます。

リスクは分かった上で許容すればいいのです。そのサービスだけではカバーできないリスクであれば、別の物を組み合わせてでもリスクヘッジすればいいのです。

本来のモチベーションは、リスクを減らしたいのではなくて、もっと良くなりたい、みんなを助けたい、だからクラウドサービスを使いたいんだって思いを現場が持っているって事を、監査や評価のタイミングでも忘れないようにしたいですね。