クラウドを利用していた場合に、設定変更がなされたとして、その設定変更に対して対応できていなかった場合にどのような問題が起きるのかというのを考えていて、「責任共有モデル」という用語をめぐって議論がなされているのですこしメモします。
まず、私のブログのなかでコンスタントにビューがあるのが、「責任分界点」のエントリです。
が代表です。
要点としては、責任という用語には、
(１）行為をなすべき義務を負う(responsible)という場合
と
（２）一定の問題が起きたときに、誰が責任を負うか（liable）
とがある。そして、
(1)については、もっとも一般的な用法は、設備についての技術基準適合義務を負う場合であり、
(2)については、Liablityを考えるときには、各行為者が、どのような予見可能性があって、具体的な回避可能性は、どうなのという具体的な事案に応じて、Liablityが決まっていくので、どこかの一点を基準に、行為者の責任が100対ゼロということにはならない
ということです。
でもって、「責任共有モデル」というのは、どうなのかということを考えてみます。
この点について記述がされているのは、「責任共有モデルとは何か、を改めて考える」になるかとおもいます。
これについては、まず、ここでいう責任が、(1)の意味であることになります。
これは、“Shared Responsibility Model”がもとの用語であることからもはっきりしています。そして、このもとで責任とは、
customer’s operational burden(利用者の運用上の負担)
であるとされています。
ちょっと図にしてみました。
(アマゾン語法とユーザとカスタマが逆転していますがご容赦を)
このサービス提供者のドメイン内での運用上の負担の分担の相互の定めというとこになるので、これは、当事者間での合意でもって決まる部分になります。
あと、こんなブログもありますね。(「アマゾンのAWS規約を法的に支える「責任共有モデル」」)
でもって、「設定ミスによる情報漏えい発生。あなたはどちらの担当者タイプ?」という記事は、面白く読みました。
まずは、カスタマに対しては、誰が当事者なのか、ということになりますから、記事でいう担当者Aの選択しかないわけです。
一方、そうはいっても、ということになり、具体的には、Saas提供者も、利用状況等から、カスタマのセキュリティ状態に対して、一定の配慮(注意義務)があるのではないかという問題提起と考えることもできそうです(担当者Bのスタンス)。
Saas提供者は、実際の利用状況とかにおいて、当事者間で、基準適合義務しか負っていません、あとは、カスタマーに被害が生じても、関係ありませんという立て付けだとしても、実際の運用においては、カスタマーに対しての一定の配慮すべき地位にはあるように思えます。ここら辺は、比較法的な配慮とかも分析なので、詳細は、別途ということになりますが、考察の立て付けが違うことは、念頭に置いておくべきでしょう。(たとえば、設定ミスによるインシデトが社会問題となっていた場合場合に、カスタマに対して、当事者間の定めがあることをもって提供者のライアビリティを否定できるとは思えません)
この問題も、責任という用語の二義性から生じるギャップの例ともいえそうだなあと考えました。
