クラウドのユーザーとグループ

5 分

リソースにアクセスしているユーザーがわからない場合、クラウドリソースに適用されるアクセス許可は役に立たないため、ID はクラウドの管理において重要な役割を果たします。 VM を削除するアクセス許可を持っていない Bob が、それでも VM を削除しようとしたときは、Bob であることがわかっている場合にのみそれを阻止できます。ただし、Bob が組織内の何千人もの従業員の 1 人で、個々のユーザーと個々のクラウドリソースごとにアクセス許可を定義する必要がある場合、IT 部門はリソースにアクセスできる ユーザー のみが それらのリソースに アクセスできるように、すべてをロックダウンしようとして圧倒されます。

後で学習するように、アクセス許可は個々のクラウドリソースだけでなく、クラウドリソースのグループにも適用できます。同様に、Bob のようなユーザーをグループに配置することができ、クラウドリソースに適用されるアクセス許可では、個々のユーザーだけでなくユーザーグループを参照することもできます。最新の ID 管理システムでは、クラウド管理を簡素化し、エラーの可能性を減らすために、ユーザーグループの概念がサポートされています。管理者は、すべてのユーザーに個別にではなく、グループレベルでアクセス許可を適用できれば、間違いを犯す可能性が低くなります。

ID 管理システムでは、個々のユーザーだけでなくグループにも ID を割り当てることができる必要があります。しかし、それだけではありません。ユーザーは、認証を行うときに、ユーザー名とパスワードを入力することも、生体認証リーダーに指を押し当てることもあります。ソフトウェアアプリケーションでも、呼び出し元の ID がわかっている場合にのみ応答する他のサービスやアプリケーションと通信する可能性があるため、認証を行うことが必要になる場合があります。そのため、ユーザーやユーザーグループに割り当てるのと同じように、アプリケーションにも ID を割り当てられるようにすることが重要です。

その結果、エンタープライズディレクトリサービスでは、ユーザー、ユーザーグループ、アプリケーションの 3 種類のエンティティがサポートされています。ユーザーは、組織内の個人を表します。グループはユーザーまたは他のエンティティのコレクションであり、アプリケーションエンティティを使用すると、実行中のアプリケーションに ID を割り当てることができます。総称して、これらは セキュリティプリンシパルと呼ばれます。ここでは、3 種類のセキュリティプリンシパルについて調べ、クラウド管理でのそれらの重要性について説明します。

ユーザー

ユーザーは、コンピューターシステム内で何らかの機能 (または機能のセット) を実行するためのアクセス許可を持つ登録済みの ID です。ユーザーによっては、クラウドでプロビジョニングされたストレージサービスにデータをアップロードするためのアクセス許可は付与されても、そのようなサービスのプロビジョニングまたはプロビジョニング解除は許可されない場合があります。別のユーザーには、サービスのプロビジョニングとプロビジョニング解除を自由に実行できる、さらにグローバルなアクセス許可が付与される場合があります。

ユーザーは、組織内の個々のユーザーを抽象化したものです。そのため、名前、電話番号、住所、および個人を区別する他の特徴が含まれる属性を持っています (図 3.2)。これらの属性は、ユーザーの情報を人間が判読できるようにするためにも役立ちます。 "48d31887-5fad-4d73-a9f5-3c356e68a038" より "Laurel King" の方が、管理者は簡単に参照できます。最新のディレクトリサービスでは、管理者は、組織にとって意味のあるスキーマを使用して、個々のユーザーの代わりに保存される属性を定義できます。

図 3.2: ユーザーを記述する属性の例。

図 3.2: ユーザーを記述する属性の例。

グループ

ID システムは多数のユーザーを処理するためにスケーリングする必要があるため、類似したユーザーのコレクションに対して抽象化を作成すると便利です。主要な抽象化は グループです。グループは、ID 管理システムにおける名前付きエンティティです。組織の構造 (経理、エンジニアリング、IT など)、職務 (開発者、テスト担当者、管理者)、地理的な場所、またはユーザーを論理的に整理するのに役立つその他のものを反映できます。ほとんどの ID 管理システムでは、ユーザーは複数のグループのメンバーになることができるので、開発者をピッツバーグオフィスの経理部に割り当てる、といったことができます。図 3.3 では、部門別にユーザーを編成するグループ構造を示します。

図 3.3: 部門別グループに編成されたユーザー。

図 3.3: 部門別グループに編成されたユーザー。

グループでは、管理設定を一括で適用できるため、組織内のユーザーのオンボードと管理が簡単になります。ユーザーが組織に加わったら、管理者は、新しいユーザーに特定のアクセス許可を個別に割り当てる必要はありません。代わりに、ユーザーを既存のグループに追加し、グループのアクセス許可を管理することに専念します。グループレベルでアクセス許可を割り当てると、エラーが発生する可能性が低くなり、管理者は、ユーザーのグループメンバーシップを調べるだけで、ユーザーが持つアクセス許可を簡単に確認できるようになります。

アプリケーション

クラウドでホストされるアプリケーションで認証を必要とするサービスを呼び出すときは、追加の考慮事項が必要です。資格情報は、アプリケーションに付随する構成データに格納することも、アプリケーションのコードに埋め込むこともできます。ただし、どちらでもセキュリティ上のリスクが発生します。アプリケーションがホストされているクラウドサービスまたはアプリケーション自体のソースコードへのアクセス権を持つユーザーは、この方法で格納された資格情報を読み取ることができます。

別の方法として、クラウドサービスプロバイダーでは、ホストされているアプリケーションに、実行時にシステムによって割り当てられた ID を提供できるようになっています。この機能は、Azure ではマネージド ID、GCP ではサービスアカウントと呼ばれています。 AWS では、ロールをインスタンスにアタッチし、それを利用してアプリケーションが使用する一時的な資格情報を取得できるようにすることで、同様の機能が提供されています。クラウドソリューションによってアプリケーションについて "認識" されていて、セキュリティで保護されたリソースにアクセスするための ID を提供できるという事実により、ユーザー名とパスワードまたはアクセスキーなどの資格情報をアプリケーションで保存する必要がなくなります。

フィードバック

このページはお役に立ちましたか?

クラウドのユーザーとグループ

自分の知識をチェックする

フィードバック