誰が何をしてよいか

7-1　本人かどうかを確かめる（認証）

クラウドの操作はすべて「誰が」から始まります。まず確かめるのは、名乗っているとおりの本人かどうかです。これを認証と呼びます。

確かめ方は 3 種類に分けられます。知っていること（パスワード）、持っていること（スマートフォン、カード）、その人自身であること（指紋、顔）です。

このうち 2 種類以上を組み合わせるのが多要素認証です。パスワードだけだと、漏れた時点で誰でも入れてしまいます。種類の違う確認を足しておくと、片方が漏れただけでは入れません。

ID は人とは限らない

操作するのは人だけではありません。プログラムも、借りたコンピューターそのものも、クラウドを操作します。だから、それらにも ID が与えられます。

ここを押さえておくと、あとの章が読みやすくなります。「このプログラムにこの権限を与える」という言い方が普通に出てくるからです。

7-2　やってよいかを決める（認可）

本人だと分かっても、それだけでは何もできません。次に、その操作をしてよいかを判定します。これが認可です。

認証と認可は必ずこの順で、かつ別の判定です。ログインはできるのに操作が断られる、ということが起きるのは、認証は通ったが認可で落ちているからです。

どの範囲に付けるか

権限には、効く範囲があります。これをスコープと呼びます。同じ「変更してよい」でも、全体に付けたのか、ひとまとまりに付けたのか、特定の 1 つだけに付けたのかで、意味がまったく変わります。

• 全体 —— 会社で借りているものすべて。ここに付けるのは例外的な場面だけです。
• まとまり —— 「この案件のぶん」のような区切り。実務でいちばんよく使う範囲です。
• 個別 —— この 1 つだけ。絞りたいときに使います。

7-3　必要なぶんだけ渡す

ここまでを踏まえると、権限の渡し方の原則が 1 つに定まります。仕事を終えるのに必要なぶんだけ渡す、という考え方です。最小権限と呼びます。

多めに渡しておくほうが、その場は楽です。何かを頼まれるたびに権限を足す手間が省けます。それでも最小にするのは、渡した権限がそのまま被害の上限になるからです。

• アカウントが乗っ取られたとき、攻撃者にできることは、その人が持っていた権限の範囲までです。
• 操作を誤ったとき、消せてしまうものの範囲も同じです。
• どちらも「本当は要らなかった権限」のぶんだけ、被害が大きくなります。

実務での付け方

人ひとりずつに権限を付けていくと、入社や異動のたびに手作業が増え、辞めた人の権限が残ります。そこで、役割ごとのまとまりを作って、そこに権限を付けます。人はまとまりに入れるだけにします。

次の章で第 0 部は最後です。ここまで出てきたものに、実際どうお金がかかるのかを見ます。