IBM Cloud Identity and Access Management とは何ですか?

ID およびアクセス管理 (IAM) を使用すると、プラットフォーム・サービスのユーザーを確実に認証でき、IBM Cloud プラットフォーム全体でリソースへのアクセスを制御することができます。 一連の IBM Cloud サービスでは、アクセス制御に Cloud IAM を使用することができます。 それらのサービスは、ユーザーが一度に複数のリソースに素早く簡単にアクセスできるように、アカウント内で複数のリソース・グループに編成されています。 ご使用のアカウント内のリソースへのアクセス権限をユーザー、サービス ID、およびトラステッド・プロファイルに割り当てるために、Cloud IAM アクセス・ポリシーが使用されます。 詳しくは、IBM Cloud Identity and Access Management を参照してください。

IAM 対応サービスとは何ですか?

IAM 対応サービスはリソース・グループに含まれている必要があり、そのサービスへのアクセス権限は IAM アクセス・ポリシーを使用して付与されます。 IAM 対応サービスをカタログから作成する場合は、それをリソース・グループに割り当てる必要があります。 詳しくは、『リソースの管理』を参照してください。

IBM Cloud Kubernetes Service は唯一の例外です。IAM でアクセス制御されますが、常にデフォルトのリソース・グループに割り当てられます。 したがって、カタログから作成するときにリソース・グループを選択することはできません。 また、他のどのリソース・グループにも割り当てることができません。

IAM アクセス・ポリシーとは何ですか?

IAM アクセス・ポリシーは、アカウント内のユーザー、サービス ID、トラステッド・プロファイル、アクセス・グループに IAM 対応の特定のサービスやリソース・インスタンスの処理、リソース・グループの管理、アカウント管理タスクの実行のための許可をどのように付与するかを指定するためのものです。 各 IAM アクセス・ポリシーは、サブジェクト、ターゲット、役割で構成されます。 サブジェクトは、誰がアクセス権限を持っているのかを示します。 ターゲットは、サブジェクトが何にアクセスできるのかを示します。 そして、役割には、選択されたターゲットのコンテキストに応じてプラットフォーム役割とサービス役割があり、サブジェクトがターゲットに対してどのレベルのアクセス権限を持つのかを定義します。

サブジェクトとは、ユーザー、サービス ID、トラステッド・プロファイル、またはアクセス・グループです。 ターゲットとは、アカウント内のサービス、アカウント内のリソース・グループ、特定のリソースのインスタンスまたはタイプ、アカウント管理サービスのいずれかです。 また、選択項目として提供される役割は、選択したターゲットに応じて異なります。 一部のサービスは定義済みのサービス固有の役割を持ちますが、プラットフォーム役割しか使用しないサービスもあります。 この概念を視覚的に理解するには、IAM ポリシーを作成するためのオプションの概要を示す以下のグラフィックを確認してください。

自分のアクセス権限を確認するにはどうしたらいいですか?

IBM Cloud コンソールで、「管理」 > **「アクセス (IAM)」**に移動し、「ユーザー」ページで自分の名前を選択します。 次に、探しているアクセス権限に応じて、以下の各種タブを開きます。

• 自分に割り当てられているアクセスグループを通じて、どのようなアクセス権を持っているかを確認するには、 ［アクセス］を選択し、［アクセスグループ］テーブルを表示します。
• 自分に割り当てられているIAMアクセスポリシーを確認するには、 ［アクセス］を選択し、［アクセスポリシー］テーブルを表示します。

各 IAM 役割にマップされているアクションは何ですか?

新規ユーザーを招待するとき、またはユーザーに IAM アクセス権限を割り当てるときに、各役割に関連付けられているアクションを表示できます。 特定の役割にマップされているすべてのアクションのリストを表示するには、各役割の横にリストされている番号をクリックします。 役割へのアクションのマッピングを確認することで、割り当てようとしているアクセス権限を確実に把握できます。

リソースへのアクセス権限はどのように要求しますか?

アカウント所有者は、自身のアクセス権限を、アカウント内のどのリソースに対しても更新できます。あるいは、サービスまたはサービス・インスタンスで管理者役割が割り当てられているどのユーザーにも連絡することもできます。

ユーザーや自分の IAM ID を見つけるにはどうすればよいですか?

IBM Cloud コンソールで**「管理」** > **「アクセス (IAM)」と移動し、「ユーザー」**を選択します。 次に、リストから自分の名前または別のユーザーの名前を選択します。 「ユーザーの詳細」ページに、そのユーザーの IAM ID と E メール・アドレスがあります。

特定のユーザーのプラットフォーム管理役割とサービス・アクセス役割を調べるには、どうしたらよいですか?

1. IBM Cloud® コンソールで 「管理」 > 「アクセス (IAM)」 をクリックして、「ユーザー」 を選択します。
2. リストから自分の名前または別のユーザーの名前を選択します。
3. ユーザーに関連付けられている権限を表示するには、［ アクセス ］をクリックします。

アカウントの所有者には、「owner」タグが表示されます。 このユーザーには、サービスまたはサービス・インスタンスに対する管理者役割が割り当てられています。

ユーザーや自分の API キーを見つけて管理するにはどうすればよいですか?

IBM Cloud コンソールで、管理 > アクセス (IAM) > API キーに移動して、アクセス権限を持つ API キーを表示および管理します。

• ユーザー ID に関連付けられた IBM Cloud API キーの管理方法については、ユーザーの API キーの管理を参照してください。
• サービス ID に関連付けられた API キーの管理方法については、サービス ID の API キーの管理を参照してください。
• クラシック・インフラストラクチャー API キーの管理方法については、クラシック・インフラストラクチャー API キーの管理 を参照してください。

サービス資格情報の確認や追加はどこでできますか?

サービスの既存のサービス・クレデンシャルを表示したり、新しいクレデンシャルを追加するには、 ナビゲーション・メニュー・アイコン > Resource list をクリックしてリソース・リストに移動し、サービス名を選択してその詳細を開きます。 **「サービス資格情報」をクリックして、詳細を確認するか「新規資格情報」**を選択します。

サービス資格情報のコピーを保存するために、ほとんどのサービスにはダウンロード・オプションまたはクリップボードにコピーするオプションが用意されています。

なぜリソース・グループとアクセス・グループを使用するのですか?

リソース・グループは、リソースの論理コンテナーです。 リソースの作成後、リソース・グループに割り当てます。その後はリソースを移動できません。

アクセス・グループは、一連のユーザー、サービス ID、およびトラステッド・プロファイルを単一のエンティティーに簡単に編成して、アクセス権限の割り当てを容易にするために使用されます。 アクセス・グループに単一のポリシーを割り当てて、それらのアクセス権限をすべてのメンバーに付与することができます。 同じアクセス権限を必要とする複数のユーザーまたはサービス ID が存在する場合は、個々のユーザー、サービス ID、またはトラステッド・プロファイルごとに同じアクセス権限を複数回割り当てる代わりに、アクセス・グループを作成します。

リソース・グループとアクセス・グループの両方を使用することにより、限られた数のポリシーを割り当てることで、アクセス権限割り当てポリシーを簡素化できます。 ユーザーおよびサービス ID の特定のグループがアクセスする必要があるすべてのリソースを単一のリソース・グループに編成し、すべてのユーザーまたはサービス ID を 1 つのアクセス・グループにグループ化してから、リソース・グループ内のすべてのリソースへのアクセス権限を付与する単一のポリシーを割り当てることができます。

詳しくは、『リソースを編成してアクセス権限を割り当てるためのベスト・プラクティス』を参照してください。

ユーザーがリソース・グループ内にリソースを作成できるようにするにはどうすればよいですか?

リソース・グループ内にリソースを作成するには、ユーザーは 2 つのアクセス・ポリシーを持っている必要があります。1 つはリソース・グループ自体に割り当てられ、もう 1 つはグループ内のリソースに割り当てられます。 リソース・グループ自体へのアクセス権限は、単にリソースを編成するコンテナーへのアクセス権限です。このタイプのポリシーでは、ユーザーはグループを表示または編集したり、グループのアクセス権限を管理したりできますが、グループ内のリソースを操作することはできません。 リソース・グループ内のサービスへのアクセス権限により、ユーザーはサービス・インスタンスを処理できます。つまり、ユーザーはサービス・インスタンスを作成できます。

したがって、ユーザーは少なくとも以下のアクセス権限を持っている必要があります。

• リソース・グループ自体に対するビューアー以上の役割
• リソース・グループ内の特定のサービスまたはすべてのサービスに対するエディター以上の役割

すべてのリソース・グループにアクセス権限を割り当てるにはどのようにすればよいですか?

ユーザー、サービス ID、またはアクセス・グループにすべてのリソース・グループのポリシーを割り当てるには、以下を割り当てる必要があります。

• Viewer リソースグループのアクセスロールが選択された、 すべての Identity and Access 対応サービスのポリシー。 ただし、このタイプのポリシーを割り当てるには、少なくとも 1 つのプラットフォーム役割またはサービス役割も割り当てる必要があります。
• **「すべてのアカウント管理サービス」で「ビューアー」**以上の役割を設定したポリシーは、すべてのリソース・グループを表示するアクセス権限を付与します。 しかし、このタイプのポリシーは、それぞれのアカウント管理サービスに対して選択する役割にも割り当てを行うので、ユーザー、アカウント設定、請求情報などを管理する権限をユーザーに付与する可能性もある強力なポリシーであることに注意してください。
• リソースグループのみのポリシーで、特定のリソースグループが選択され、リソースグループのアクセスロールが割り当てられている。 アカウントに属する使用可能なリソース・グループごとに、必要に応じてこのタイプのポリシーを繰り返すことができます。

また、ターゲットとなるリソース・グループを名前で選択し、リソース・グループ・アクセス役割を割り当てた場合、サービスに対するポリシーで個々のリソース・グループにアクセス権限を割り当てることもできます。

ユーザーが単一リソースを処理できるようにするアクセス権限は何ですか?

ユーザーには、特定のリソースに対するアクセス・ポリシーが割り当てられている必要があり、それには、そのリソースが属しているリソース・グループに対するビューアー以上の役割が割り当てられている必要があります。 このタイプのポリシーの割り当てについては、『リソースへのアクセス権限の割り当て』を参照してください。

他のユーザーにアクセス権限を付与するには、どのようなアクセス権限が必要ですか?

IAM 対応サービスの場合、ユーザーにアクセス権限を割り当てる対象となるサービスまたはリソースに対する管理者役割を持っている必要があります。 アカウント内のすべてのサービスまたはリソースにアクセスを割り当てる場合は、Administrator ロールで All Identity and Access を有効にしたサービスのポリシーが必要です。 また、アカウント管理サービスへのアクセス権限をユーザーに割り当てるには、特定のサービスまたはすべてのアカウント管理サービスに対する管理者役割が割り当てられている必要があります。 管理者役割をユーザーに割り当てると、アカウントの管理者権限の付与と取り消しが委任されます。これには、管理者役割を持つ他のユーザーのアクセス権限を取り消す機能も含まれます。

クラシック・インフラストラクチャーの場合、「ユーザーの管理」クラシック・インフラストラクチャー許可、および、ユーザーにアクセス権限を付与したいリソースに対するサービスおよびデバイスのカテゴリー許可を持っている必要があります。

リソース・グループを管理するためのアクセス権限とリソース・グループ内のリソースへのアクセス権限の違いは何ですか?

リソース・グループを管理するアクセス権限がある場合、割り当てられた役割に応じて、リソース・グループ自体の表示、名前の編集、およびアクセスの管理を行うことができます。 リソース・グループ自体へのアクセス権限では、ユーザーにグループ内のリソースへのアクセス権限は付与されません。

リソース・グループ内のリソースへのアクセス権限がある場合は、割り当てられた役割に応じて、インスタンスを編集、削除、および作成したり、リソース・グループ内の指定されたサービスに対するすべての管理アクションを実行したりできます。

アカウント管理サービスのプラットフォーム管理の役割とアクションの例については、プラットフォームの役割の表を参照してください。

ユーザーの削除は誰が行えますか?

アカウント所有者はアカウントから任意のユーザーを削除でき、以下のアクセス権限を持つユーザーはアカウントからユーザーを削除できます。

• 管理者役割が割り当てられたユーザー管理アカウント管理サービスの IAM ポリシー。
• アカウントにクラシック・インフラストラクチャがある場合、ユーザーは、管理者ロールが割り当てられたユーザー管理アカウント管理サービスの IAM ポリシーを持ち、クラシック・インフラストラクチャのユーザー階層で Manage user classic infrastructure 権限が割り当てられたユーザーの先祖である必要があります。

アカウントで多要素認証を必須にするには、どのようにすればいいですか?

1. IBM Cloud コンソールで**「管理」** > **「アクセス (IAM)」と移動し、「設定」**を選択します。
2. 「認証」セクションで**「更新」**をクリックし、すべてのユーザーに対して MFA を選択するか、非フェデレーテッド・ユーザーのみに対して MFA を選択します。

詳しくは、アカウントのユーザーに MFA が必要を参照してください。

サービスの役割とプラットフォームの役割の違いは何ですか?

サービスの役割とプラットフォームの役割は、2 つの異なるタイプの役割です。

• プラットフォームの役割は、インスタンスの作成、インスタンスのバインド、サービスへのユーザーのアクセス権限の管理など、アカウント内でのサービスの操作方法です。 プラットフォーム・サービスの場合、これらの役割により、ユーザーは例えばリソース・グループを作成し、サービス ID を管理できます。 プラットフォームの役割は、管理者、エディター、オペレーター、およびビューアーです。

• サービスの役割は、サービスに対してアクションを実行する能力を定義します。また、これは API 呼び出しの実行や UI へのアクセスなどのすべてのサービスに固有です。 サービスの役割は、マネージャー、ライター、およびリーダーです。 これらの役割の適用方法について詳しくは、特定のサービスの資料を参照してください。

ユーザーをアカウント管理者に指定して全アクセス権限を割り当てる方法を教えてください。

アカウント内のユーザーに全アクセス管理者権限を割り当てるには、コンソールで**「管理」>「アクセス (IAM)」**と移動し、ユーザー名を選択してから以下のアクセス権限を割り当てます。

• ユーザがサービスインスタンスを作成し、アカウント内のすべてのリソースへのアクセス権をユーザに割り当てることを可能にする。

• すべてのアカウント管理サービスの管理者ロールを持つIAMポリシーで、ユーザーの招待と削除、アクセスグループの管理、サービスIDの管理、プライベートカタログ製品の管理、課金と使用量の追跡などのタスクを完了することができます。

• クラシック・インフラストラクチャーのスーパーユーザー許可セット (すべての有効なクラシック・インフラストラクチャー許可を含みます)。

• 代替アカウント所有者として設定されたトラステッド・プロファイルは、最高レベルのクラシック・インフラストラクチャー許可を持ち、全アクセス権限を付与する両方の IAM ポリシーを持ちます。 詳しくは、 代替アカウント所有者の設定 を参照してください。

アカウント内のどのユーザーも他のすべてのユーザーを表示できますか?

アカウント所有者は、アカウント内のすべてのユーザーを表示することができ、「ユーザー」ページでユーザーがアカウント内の他のユーザーを表示できる範囲を選択することができます。 アカウント所有者は、「設定」ページで以下のオプションのいずれかを選択することによって、ユーザー・リスト可視性設定を調整できます。

• 無制限ビュー: アカウント内のすべてのユーザーが、アカウント内の他のすべてのユーザーを表示できます。
• 制限付きビュー ：ユーザー]ページでユーザーを表示できるのは、明示的なアクセス権を付与されたユーザーと、古典的なインフラストラクチャのユーザー階層関係を通じて他のユーザーを表示できるユーザーのみに制限されます。

ユーザーをアカウントに招待するときに、ユーザーにアクセス権限を割り当てる必要がありますか?

いいえ ユーザーを招待し、後でアクセス権限を割り当てることができます。

ユーザーが保留状態であるとはどのような意味ですか?

Pendingとしてリストされているユーザーは、IBM Cloudに招待されていて、その招待を受諾していないユーザーです。「ユーザー」ページで、これらのユーザーに対する管理アクションには、招待の再送や招待のキャンセルなどがあります。

アカウント内のアクセス・グループ・メンバーシップまたはアクセス・ポリシーを検査する場合、招待の一部として作成された、保留中のユーザーに関連するメンバーシップまたはポリシーが表示される場合があります。これらの表示には、BSS- を使用する IAM ID が含まれています。 この IAM ID は、ユーザーが招待を受け入れるまでの、メンバーシップとポリシーのプレースホルダーとなります。 また、ユーザーは IBM Cloud に登録していないため、IAM アクセス・トークンを取得して割り当てられたアクセス権限を利用することができません。 ユーザーが招待を受け入れて IBM Cloud に登録すると、これらのメンバーシップおよびポリシー内の ID は、割り当てられた IAM ID に置き換えられます。

Web アプリおよびモバイル・アプリに認証を追加するには、どのようにすればよいですか?

IBM Cloud サービスおよびリソースへのアクセス権限を管理するために、IAM が使用されます。 IBM Cloud App ID を使用すると共に、Web アプリおよびモバイル・アプリに認証を追加することによって、クラウド・セキュリティーを一歩前進させることができます。 数行のコードだけで、IBM Cloud 上で実行されるクラウド・ネイティブなアプリおよびサービスを簡単に保護できます。 始めに 資料を参照してください。

インフラストラクチャーに対するユーザーのアクセス権限はどこで管理しますか?

クラシック・インフラストラクチャーのアクセス権限は、ユーザーから始まります。 詳しくは、『クラシック・インフラストラクチャー・アクセス権限の管理』を参照してください。

IBM Cloud® Virtual Private Cloud などの IAM 対応インフラストラクチャー・サービスへのアクセス権限を割り当てる必要がある場合は、以下の手順を実行してユーザーにアクセス権限を割り当てます。

1. 「管理」>「アクセス (IAM)」>**「ユーザー」**をクリックします。
2. ユーザーを選択します。
3. 「アクセス」 をクリックします。

SoftLayer アカウントで以前に請求処理の許可とサポートの許可を割り当てたユーザーのアクセス権限を管理するには、どのようにすればよいですか?

SoftLayer アカウントで以前に割り当てたすべての許可は、IBM Cloud コンソールで管理できます。 請求処理情報とサポート Case を管理するためのアカウントの許可について、マイグレーションされた SoftLayer アカウント許可の管理で参照できるようになりました。 SoftLayer アカウントで以前にこれらの許可を割り当てられていたすべてのユーザーは、アクセス・グループで IAM ポリシーを使用して同じレベルのアクセス権限が割り当てられている、これらのアクセス・グループにマイグレーションされました。

自分のアカウントにいくつのポリシーがあるかはどうすればわかりますか?

CLIを使用して、 アカウントごとのポリシーの合計数を表示し、アカウントの制限を超えないようにすることができます。

どのような検証方式がありますか、また、それらは何のために使用されますか?

検証方式は、ID を証明し、「検証方式と認証要素 (Verification methods and authentication factors)」ページにアクセスするために使用されます。

MFA 設定の更新後に初めてアカウントにログインするときにはまた、2 つの異なる検証方式を使用して ID を検証する必要があります。 検証方式には、E メール、テキスト・メッセージ、電話があります。これらのオプションの任意の組み合わせを使用して ID を検証することができます。 本人確認後、 「認証方法と認証要素 」ページで認証要素を設定し、詳細を入力します。

認証要素とは何ですか、また、それらは何のために使用されますか?

これらの要素には、U2F セキュリティー・キーのようなものや、ユーザーが受け取る時間ベースのワンタイム・パスコード (TOTP) や OTP のようなものがあります。 ユーザーがメンバーであるアカウントうち 1 つ以上で管理者が MFA を有効にすると、ユーザーはログインするたびに 2 つ以上の要素を提供する必要があります。 複数のアカウントのメンバーになっている場合に、それらのアカウントの 1 つ以上で MFA が使用されていると、ログインするたびに MFA が要求されます。 このことは、アクセスしようとしているアカウントに関係なく当てはまります。 詳しくは、検証方式と MFA 要素の管理を参照してください。

検証方式をリセットするにはどうすればよいですか?

ID に関連付けられている電話番号や E メール・アドレスが変わったり、それらを使用できなくなると、検証方式にアクセスできなくなります。 検証方式をリセットするには、サポート Case を開き、「検証方式と認証要素 (Verification methods and authentication factors)」ページへのアクセスに使用できる検証方式を追加します。

MFA セットアップ用の新規 QR コードはどのように取得できますか?

MFAセットアップ用の新しいQRコードを取得するには、「 Verification methods and authentication factors（認証方法と認証要素） 」ページにアクセスしてください。 「認証要素 (Authentication factors)」セクションで、「認証要素を表示する (Show authentication factors)」 > **「追加 (Add)」をクリックします。 次にタイプを選択し、「TOTP」**を選択します。 その後、新規 QR が使用可能になります。 QR コードをスキャンしたら、オーセンティケーター・アプリにより生成された TOTP を入力し、選択内容を確認します。 これで、セットアップしたオーセンティケーター・アプリが生成した TOTP をログインのたびに指定できるようになります。

MFA に使用する E メール・アドレスはどのようにしたら変更できますか?

MFAに使用するEメールアドレスは、「 検証方法と認証要素 」ページで更新できます。 「認証要素 (Authentication factors)」セクションで、「認証要素を表示する (Show authentication factors)」 > **「追加 (Add)」**をクリックします。 **「E メールで (Email-based)」を選択し、認証要素として OTP を受信する E メール・アドレスを入力します。 次に、受信した OTP を入力して選択内容を確認します。 次に、「完了 (Complete)」をクリックします。 新規要素を追加したら、古い E メール・アドレスを選択し、「削除 (Remove)」**をクリックします。

トラステッド・プロファイルでユーザー API キーを作成できますか?

トラステッド・プロファイルを使用している場合、ユーザー API キーを作成することはできません。 とはいえ、他のすべての API キーは作成して管理することができます。 例えば、サービス ID API キーなどがあります。

ユーザー API キーを作成するには、使用している IAM ID が、ユーザー API キーを要求しているユーザーの IAM ID と同じでなければなりません。 トラステッド・プロファイルを適用する場合は、そのプロファイルの IAM ID を使用します。 ID のユーザー API キーを作成するには、アカウントスイッチャーを使用して、信頼済みプロファイルから IAM ID がメンバーであるアカウントに切り替えます。

ユーザーが信頼できるプロファイルを適用できるかどうかを確認するにはどうすればよいですか?

ユーザーが IBMid ID プロバイダー (IdP) を使用してトラステッド・プロファイルを適用する資格があるかどうかを確認するには、ユーザーと管理者が特定のステップを実行する必要があります。

1. ユーザーは IBM Cloud ユーザー請求に移動する必要があります。
2. ここから、クレームが表示されます。
3. ユーザーは、管理者にクレームを提供する必要があります。
4. 管理者として、ユーザーのクレームを、トラステッド・プロファイルに設定されている条件と比較します。 トラステッド・プロファイルの条件を表示するには、IBM Cloud コンソールの管理 > アクセス (IAM) > トラステッド・プロファイルに移動します。
5. プロファイルをクリックして、条件列を表示します。
6. ユーザーのクレームがすべての条件を満たす場合、ユーザーはプロファイルを適用できます。

別の IdP を使用している場合は、企業ディレクトリー内のユーザーの請求を確認してください。 次に、ユーザーのクレームを、トラステッド・プロファイルに設定された条件と比較します。 クレームとルールが一致する場合、ユーザーはプロファイルを適用できます。

信頼できるプロファイルで Kubernetes サービスとの信頼を確立するにはどうすればよいですか?

Kubernetes では、サービス・アカウントはポッドで実行されるプロセスの ID を提供し、名前空間は単一クラスター内のリソースのグループを分離するためのメカニズムを提供します。 すべての Kubernetes クラスターにはdefault名前空間があり、各名前空間にはdefaultアカウントがあります。

信頼できるプロファイルで Kubernetes サービスとの信頼を確立する場合は、namespaceフィールドとservice accountフィールドに情報を入力する必要があります。 両方にdefaultを入力できます。

詳しくは、 Using Trusted Profiles in your Kubernetes and OpenShift Clusters and Kubernetes namespaceを参照してください。

アクセス・グループの動的メンバーを表示するにはどうすればよいですか?

アクセス・グループ内の動的メンバーのリストを表示するには、IBM Cloud コンソールで**「管理」>「アクセス (IAM)」>「アクセス・グループ」に移動します。 アクセス・グループを選択して、「ユーザー」**をクリックします。 動的に追加されたユーザーは、Dynamic タイプで示されます。 詳しくは、アクセス・グループの動的メンバーの表示を参照してください。

アカウント内の非アクティブなユーザー、サービス ID、信頼できるプロファイル、および API キーを見つけるにはどうすればよいですか?

アカウント内の非アクティブな ID のリストを表示するには、 「管理」 > 「アクセス (IAM)」 > 「非アクティブな ID」 に移動します。 非アクティブな ID が不要になった場合は、削除することをお勧めします。 詳細については、「 非アクティブなIDの識別 」を参照。

信頼できるプロファイルとアカウントを切り替えるには？

コンソールのメニューバーにあるアカウントスイッチャーを使うことで、信頼できるプロファイルと、自分がメンバーであるアカウントを切り替えることができます。

どのアカウントのメンバーでもない場合は、一旦ログアウトしてログインし直し、別の信頼できるプロフィールを選択する必要があるかもしれません。 そのためには、以下の手順を実行する。

1. ログアウト Avatar icon Log out.
2. 確認するには、 ログアウトをクリックします。
3. https://cloud.ibm.com/login 、再度ログインする。
4. 認証情報を入力し、 Continueをクリックします。
5. 信頼済みプロファイルのランディングページで、信頼済みプロファイルを選択します。