IBM Cloud 101 - #2 IBM Cloud の IAM を理解(ワカ)る

Transcript

1. IBM Cloud 101 #2 IBM Cloud の IAM を理解(ワカ)る IBM Tech/Developer Dojo 101
2. 2 © 2022 IBM Corporation IBM Cloud とは 企業の“Journey to Cloud”を⽀えるのがIBM Cloudです。VMWare vSphere や Power AIXのよう な現⾏システムのクラウド移⾏からクラウドネイティブによるDX実現までサポートします。 モノリスに 実装された レガシーアプリ レガシーアプリ をIBM Cloudへ そのまま移⾏ コンテナにより リファクタ リングされた レガシーアプリ Cloud Hosted VMware VM / PowerVMを パブリッククラウドにLift & Shiftし、迅速な速度と スケール・メリットを実現 Containerized アプリを再設計せずに、ステートレス なアプリをコンテナ化。ステートフル なアプリはそのままに。 既存アプリのクラウド・サービス連携 とCI/CDの確⽴による アジャイル・ク ラウド運⽤の実現 Cloud Native お客様のペースに合わせてアプリ を再構築するか、マイクロサービ ス、コンテナ、DevOpsツールを活 ⽤して、まったく新しいアプリを クラウドで構築 レガシーアプリ からIBM Cloud サービスを利⽤ Cloud Enabled VMをパブリッククラウド サービスに拡張すること により、VMをLift & Transform IBM Cloud Microservices Analytics IBM Watson Object Storage Machine Learning IBM Kubernetes Service IBM Cloud 190+ サービス Microservices RedHat OpenShift Kubernetes Service オンプレミス IBM Cloud Kubernetes Service RedHat OpenShift Kubernetes Service
3. IBM Cloud 101 #2 IBM Cloud の IAM を理解(ワカ)る 1. IBM Cloud の IAM とは︖ 3 © 2022 IBM Corporation
4. 1. IBM Cloud の IAM とは︖ (1) そもそもIAMとは︖ 4 主要なクラウド・サービスには、Identity Access Management (IAM) と呼ばれる機能が備わっています。 IAM は、クラウドのリソースへのアクセスを安全に管理するための仕組みで、ID と アクセス権限を管理する役割を担います。 複数の⼈がクラウドのアカウントを利⽤する場合、誰が、どのリソースに、どのような操作を⾏えるのかを管理する必要があります。 IAM は複数のユーザと権限を柔軟に管理するための機能を提供します。 © 2022 IBM Corporation セキュリティ ユーザーと重要なエンタープライズ資産の間に位置する IAM は、あらゆるエンタープライ ズ・セキュリティー・プログラムの重要なコンポーネントです。 IAMは、ランサムウェアを仕掛けたり、データを盗んだりしたい犯罪ハッカーにとって⼀般 的なネットワーク侵⼊ポイントである、ユーザー資格情報の漏洩やパスワードの簡単な 解読から保護します。 ⽣産性 適切に⾏われれば、IAMはビジネスの⽣産性を⾼め、デジタル・システムが摩擦なく機 能するようにできます。 従業員がどこにいてもシームレスに働くことができる⼀⽅、⼀元化した管理により、仕事 に必要な特定のリソースにのみアクセスすることができます。 IAM が必要な理由
5. 1. IBM Cloud の IAM とは︖ (2) IBM Cloud の IAM 5 IBM Cloud の IAM は IBM Cloud でユーザーおよび管理対象のリソースを⼀貫して制御するための仕組みです。ユーザーをアカ ウントに招待し、適切なアクセス・ポリシーの権限を付与することでリソースへのアクセス管理を⾏うための中⼼的な役割を担います。 © 2022 IBM Corporation IAMの主要概念 • ID • 利⽤者を表す識別情報として、IBMidやフェデレーテッドIDで個⼈を識別する 「ユーザー」、サービスやシステムを⽰す「サービスID」がある。また、それらをグルーピ ングする「アクセス・グループ」という概念もある。 • アクセス管理 • アカウント内のリソースを操作を実施できるよう権限を設定する。 • 設定時には「ポリシー」を作成し「ID」に割り当てる。 • 「ポリシー」は操作対象となる「リソース」（ 「リソース・グループ」、 「サービス」、 「サービス・インスタンス」）とそれらを操作するための「ロール」から構成される。
6. 1. IBM Cloud の IAM とは︖ (3) IBM Cloud IAM のアクセス管理の対象 6 © 2022 IBM Corporation Cloud Foundry の組織とスペースの役割を使⽤ Cloud FoundryアプリケーションやCloud Foundry 組織/スペースによる認可を⾏うサービスが管理対象と なります。 IAM のアクセス・ロールを使⽤ IBM Cloudで提供されるリソース（リソース・グルー プ、サービスおよびサービス・インスタンス）のうちIAM 対応のものが該当し、管理対象となります。 クラシック・インフラストラクチャーの許可を使⽤ 従来のIBM Cloud IaaS/旧SoftLayerにより管理 されていたリソースでサーバー機器やネットワーク機器な どIaaSサービスが管理対象となります。 図. IBM Cloud のアカウントに含まれる内容 IBM Cloud のリソースにアクセス権限を付与するために使⽤できる3つのタイプのアクセス管理があります。IAM は、リソース・グルー プに属するリソースのアクセス管理を⾏います。クラシック・インフラストラクチャーとCloud Foundryは、IAMとは別の⽅法でアクセス 管理を⾏います。
7. 1. IBM Cloud の IAM とは︖ (3) IAM管理対象の⾒分け⽅ 7 IBM Cloud で IAM を利⽤可能なリソースは、カタログに「IAM対応」と表⽰されます。 © 2022 IBM Corporation
8. IBM Cloud 101 #2 IBM Cloud の IAM を理解(ワカ)る 2. ID 管理 8 © 2022 IBM Corporation
9. 2. ID 管理 (1) IBM Cloud の ID の種類 9 IBM Cloud の ID 関連の概念として、アカウント所有者 / ユーザー / サービス ID / アクセス・グループがあります。 © 2022 IBM Corporation アクセス・グループ アカウント所有者 ユーザー サービス ID • アカウント内のユーザーおよびリソースに関する全ての権限を有し、管理する責任を負う担当者 • IAMのアクセス管理において、全ての権限が付与され、アカウント内のユーザーにアクセス権限/ポリ シーを付与できる • アカウントに招待され、アカウントのリソースに対して作業を実施する担当者 • IBMidやSSOにより認証される個⼈の利⽤者 • アカウント所有者もしくは管理権限を付与されたユーザーによりアクセス権限が付与され、付与され た権限/ポリシーの範囲で作業を実施できる • 複数のユーザーやサービスIDをまとめてグループとしたもの • アクセス権限付与時にアクセスグループにポリシーを適⽤することで、所属するユーザーやサービスID に権限の付与をまとめて実施することができる • アカウント内に作成され、システムやアプリケーションを⼀意に表すID • ユーザーのように組織や所属の影響を受けにくいユーザーとして運⽤することが可能になる
10. 2. ID 管理 (2) ユーザー 10 IBM Cloud のユーザーは、IBMiD とフェデレーテッド ID の2種類の⽅法で登録できます。 © 2022 IBM Corporation IBMid ü ⼀般のユーザーは個⼈単位でご利⽤いただくことを想定している。 ü ユーザー ID としては IBMid (Eメールアドレス)を利⽤する。 ü アカウント所有者もしくはアカウント管理サービスの管理権限を持つユーザーが招待 することでユーザーがアカウントへのユーザー登録が⾏われる。 ü 登録時に IBMid を持たないユーザーには招待メールが送信され、メール内のリン クから IBMid を登録することでIBM Cloudの利⽤を開始できる。 フェデレーテッド ID ü IBM Cloud では、IBMid とお客様管理のアイデンティティ・プロバイダ (IdP) との 間のフェデレーション機能を提供している。 ü お客様組織が利⽤している既存のログイン機能と連携し、SSO 認証でIBM Cloud にログインすることが可能。 ü トラステッド・プロファイルを使⽤すると、企業のディレクトリーの SAML 属性に基づく 条件を使⽤して、フェデレーテッド・ユーザーにアカウントに対するアクセス権限を⾃ 動的に付与することができる。※ IBM Cloud のユーザ ID IBM Cloud の ログイン機能 IdP の SSO 認証 ユーザーの種類 概要 認証⽅法 ※トラステッド・プロファイルは、多数のユーザを管理することに適した機能です。詳細はこちらをご参照ください。
11. 2. ID 管理 (3) サービス ID 11 サービス ID は⼀般のユーザーと同じように、サービスやアプリケーションに付与することができる ID です。IBM Cloud 内外の別の サービスからサービスを利⽤するときに利⽤します。 © 2022 IBM Corporation Ø サービス ID は、サービスやアプリケーションに付与できるID ü サービス ID は、特定のユーザーに関連づけられるわけではない ü ⼈事異動などによるユーザーへの権限付与等の変更に影響を受けることなく、継続的に利⽤し続けることができる ü IBM Cloud の外部で稼働するシステムやアプリケーションから、IBM Cloud で稼働するサービスを呼び出す場合や、 IBM Cloud 内の複数のサービスを組み合わせる場合に利⽤する。 Ø 認証時には ID に加え固有の API キーが必要となる。 ü API キーはサービス ID に複数設定できる。 ü API キーは作成時に⾃動的に⽣成され、1度だけ画⾯上に表⽰される。 ü 値を取得して適切に管理する必要がある。 ü 値が分からなくなってしまった場合には新たな API キーを作成する。 Ø サービス ID は IBM Cloud 内の複数のサービスを跨いで利⽤する場合に⾃動的に⽣成されることがある。
12. 2. ID 管理 (4) アクセス・グループ 12 アクセスグループは複数のユーザーやサービスIDに同⼀のアクセスポリシーを適⽤するための機能です。アクセ ス・グループを活⽤することで、複数の ID をまとめてアクセス管理できるため、IBM Cloud のアカウント内の アクセス管理を効率的に⾏うことができます。 © 2022 IBM Corporation ユーザー リソース アクセス・グループ リソース • アクセス・グループは、チームや役割に応じて同⼀のアクセスポリシーを持つべきユーザーをグループ化し、アクセスポリ シーの管理を簡略化するための機能 • ⼈事異動やプロジェクト体制の変更などでメンバーや管理対象を動的に変更できる • アクセス・グループにはリソースを含めることはできず、ユーザーとサービスIDのみを含むことができる • アクセス・グループに含むメンバーには、『アクセス・グループにより設定されたアクセスポリシー』と、『ユーザーに個別 に付与されているアクセスポリシー』の両⽅が適⽤される アクセス・グループを利⽤しない場合 アクセス・グループを利⽤する場合 ユーザやサービスIDを個別 にアクセス管理 ユーザやサービスIDをまとめ てアクセス管理
13. 2. ID 管理 (5) 多要素認証 13 IBM Cloud では、ID の多要素認証 (MFA) をサポートしています。MFA には、ID ベースとアカウント・ベースの2種類があります。 MFA を有効化することで、ID とパスワードに加えて追加の認証要素が要求されるようになり、より安全に IBM Cloud を利⽤する ことができるようになります。セキュリティ向上の⽬的で、MFA を有効化することを推奨します。 ID ベースの MFA は、IBMid に関連付けられており、⾃分がメンバーになっているすべてのアカウントで認証されます。アカウント・ ベースの MFA は、アカウントごとの多要素認証を設定しますが、クラシック・インフラストラクチャー・アカウントでのみ使⽤可能です。 © 2022 IBM Corporation Ø 可能なMFAの設定 • なし – 全てのユーザーで多要素認証を使⽤しません。 • ⾮フェデレーテッド・ユーザーのみ – お客様の認証プロバイダーをフェデレーションされているユーザーでは 多要素認証を使⽤せず、その他のユーザーでは多要素認証を使⽤します。 • すべてのユーザー – すべてユーザーで多要素認証を使⽤します。 Ø ID ベース MFA で利⽤可能な認証要素 • E メール・ベース MFA (Email-based MFA) - ユーザーは E メールで送信されるセキュリティー・パスコードを使⽤して認証を ⾏います。 • TOTP MFA - ユーザーは TOTP を使⽤して認証を⾏います。 • U2F MFA - ユーザーは 6 桁の数値コードを⽣成する物理ハードウェア・ベースのセキュリティー・キーを使⽤して認証を⾏いま す。 FIDO U2F 標準に基づき、この要素は、最⾼のレベルのセキュリティーを提供します。
14. IBM Cloud 101 #2 IBM Cloud の IAM を理解(ワカ)る 3. アクセス管理 14 © 2022 IBM Corporation
15. 3. アクセス管理 (1) アクセス・ポリシー 15 © 2022 IBM Corporation アクセスポリシーはアカウント内のユーザー、サービスID、アクセスグループがリソースにアクセスする許可を 与えるためのルールを定義したものです。 Ø アクセスポリシーには、アクションの主体となる『サブジェクト』がどの『ターゲット』に対してどのような『ロール』を持つかを定義します。 Ø コンソール上でサブジェクト、ターゲットの選択ならびにロールの設定まで全てをGUI画⾯上で実施できます。 ※サブジェクト … ユーザー、サービスID、アクセスグループ ※ターゲット …リソース, リソース・グループ ※ロール …アクションを実施できる役割 図 1. サブジェクト、ターゲット、役割を使⽤して IAM アクセス・ポリシーを作成する⽅法 ※アクセス管理タグを利⽤したリソースのアクセス権限の管理の⽅法もあります。詳しくはこちらをご参照ください。
16. 3. アクセス管理 (2) リソース・グループ 16 © 2022 IBM Corporation リソース・グループはリソースを効率的に構成し管理するための機能です。 • 論理的にリソースをグループ化してまとめて編成/管理することができます。 • 複数のチームで同⼀アカウントを共同利⽤する場合や同じチームが複数の環境を利⽤する必要がある場合に⽤います。 • リソース・グループにはリソースのみが属し、ユーザーは含まれません。 ▪リソースにおける制約 • リソースは必ず⼀つのリソース・グループに所属する。 • ⼀度設定したリソース・グループを変更することはできない。 • IAM対応リソースのみを含むことができ、クラシック・インフラストラクチャー、Cloud Foundryのリソースを含むことはできない。 リソース・グループ #1 (システム A – 本番) リソース (サービス・インスタンス) リソース (サービス・インスタンス) リソース (サービス・インスタンス) リソース・グループ #2 (システム A – 検証) リソース (サービス・インスタンス) リソース (サービス・インスタンス) リソース (サービス・インスタンス) リソース・グループ #3 (システム A ‒ 開発) リソース (サービス・インスタンス) リソース (サービス・インスタンス) リソース (サービス・インスタンス) リソース・グループ #N (システム B – 本番) リソース (サービス・インスタンス) リソース (サービス・インスタンス) リソース (サービス・インスタンス) IBM Cloudアカウント …
17. 3. アクセス管理 (3) IAM ロールの種類 17 © 2022 IBM Corporation リソースへのアクセス・ポリシーの設定には、「プラットフォーム役割」、「サービス役割」の２つのポリシー を設定可能です。権限を持つユーザーが実施すべきアクションに合わせて設定します。 プラットフォーム役割 サービス役割 • IBM Cloud上でのアクションの実⾏権限を管理するための役割 • リソースの作成や編集、ランタイムとのバインドなどが管理対象 • プラットフォーム内で共通の4つの役割を選択可能 • 各サービス内でのアクションの実⾏権限を管理するための役割 • リソースがもつ独⾃のGUIツールへのアクセス、API/CLIの実⾏など が管理対象 • サービスが定義した役割を選択可能 • 以下の3つが標準的に⽤意されている プラットフォーム役割 説明 管理者 Administrator リソースの作成や削除、アクセス権限付与の管理などす べてのアクションを実⾏できる エディター Editor リソースの作成や削除、設定の変更などのアクションを実 ⾏できる オペレーター Operator コンソール内のダッシュボードの表⽰とサービス・インスタン スの構成や操作に必要なアクションを実⾏できる ビューアー Viewer コンソール内のダッシュボードの表⽰など変更を伴わない アクションを実⾏できる サービス役割 説明 管理者 Manager リソースの状態の更新を伴うアクション、サービス内で管 理/利⽤されるサブ・リソースの管理、管理者権限が必 要なアクションを実⾏できる ライター Writer リソース内の状態の更新を伴うアクション、リソース内で 管理/利⽤されるサブ・リソースの管理アクションを実⾏で きる リーダー Reader リソース内で状態の更新を伴わない読み取りのみのアク ションを実⾏できる ※上記以外に、カスタムの要件に合わせたロール(カスタム・ロール)を作成することができます。 ※サービスによってはサービス役割が存在しないものもあります。 その場合には設定画⾯等にサービス役割が表⽰されません。
18. 3. アクセス管理 (4) アクセス管理のベストプラクティス 18 © 2022 IBM Corporation アカウントで許可されるポリシーの合計数には、制限があります。制限に達しないようにするために、また、アカウント内のユーザやサー ビスIDなどのIDのアクセス管理に費やす時間を短縮するために、以下のようなプラクティスを活⽤できます。 ü 最⼩限の特権を付与するという原則に従い、必要なアクセス権限のみを割り当てます。 こうすることで、アカウント内の ID の アクションを、許可したアクションのみに制限することができます。 ü リソースをリソース・グループに追加することによって、必要なポリシーの数をさらに少なくすることができます。 例えば、アカウン ト内の特定のリソースを使⽤するプロジェクトで作業するチームがあるとします。 そのチームのメンバーを、特定のリソース・グループ のリソースへのアクセス権限のみを割り当てるポリシーを設定したアクセス・グループまたはトラステッド・プロファイルに追加します。 そ のようにすれば、チーム・メンバーごとにそれぞれのリソースに対するポリシーを割り当てる必要はありません。 ü アクセス・グループを使⽤して、同じレベルのアクセス権限を必要とする ID のアクセス管理を合理化します。 特定のポリシー を定義したアクセス・グループをセットアップし、そのグループに ID を追加します。 後にグループ・メンバーにさらにアクセス権限が必 要になった場合には、そのアクセス・グループに新しいポリシーを定義します。 ü アクセス管理タグを使⽤して、アカウント内のリソースに対するアクセス権限を⼤きな規模で制御します。 特定のタグが付いて いるリソースに対するアクセス権限のみを割り当てることによって、定義したポリシーを何度も更新する⼿間を省くことができます。 ü トラステッド・プロファイルを使⽤することによって、フェデレーテッド・ユーザーとコンピュート・リソースにアカウントへのアクセス権 限を⾃動的に付与することができます。 この⽅法では、ログイン時に SAML ベースの属性を評価してフェデレーテッド・ユーザー が適⽤できるプロファイルを判別することにより、1 つ以上のトラステッド・プロファイルにフェデレーテッド・ユーザーをマップすることがで きます。 コンピュート・リソースにトラステッド・プロファイルを使⽤することによって、アプリケーションを実⾏するための資格情報の保 管や、資格情報の管理とローテーションの操作を回避することができます。 アクセス管理の時間と労⼒の削減のベストプラクティス(Docsより抜粋)
19. IBM Cloud 101 #2 IBM Cloud の IAM を理解(ワカ)る 4. アカウント管理 19 © 2022 IBM Corporation
20. 4. アカウント管理 (1) エンタープライズの機能 20 IBM Cloud は、エンタープライズと呼ばれる複数のアカウントの請求およびリソース使⽤量を⼀元管理する⽅法を提供しています。 エンタープライズ内に多層のアカウント階層を作成して、すべてのアカウントの請求処理および⽀払いがエンタープライズ・レベルで管理 されるようにします。 © 2022 IBM Corporation Ø ⼀元化されたアカウント管理 ü アカウントを切り替えることなく、エンタープライズ階層全体を⼀⽬で確認できます。 ü 既存のアカウントを追加することも、新規アカウントをエンタープライズ内に直接作成することもできます。 Ø 統合されたサブスクリプション請求 ü すべてのアカウントのサブスクリプションおよびクレジット消費量を 1 つのビューで追跡できます。 ü サブスクリプション・クレジットはプールされ、エンタープライズ内のアカウント間で共有されます。 Ø トップダウンの使⽤量レポート ü エンタープライズ内のすべてのアカウントの使⽤量がアカウント・グループ別に編成されたものを、エンタープライズ・アカウントから表⽰できます。 エンタープライズの階層構造 エンタープライズ全体の請求を管理し、 すべてのアカウントの使⽤コストはまとめ て⽀払われる。 関連するアカウントを編成するために 使⽤できる。 アカウント・グループ⾃体 はリソースを含むことはできない。 スタンドアロンのアカウントと同様、リ ソース、リソース・グループなどを含み、 独⽴したアクセス許可を持つ。
21. 4. アカウント管理 (2) エンタープライズの使⽤⽅法 21 エンタープライズ機能を利⽤すると、アカウントおよび請求管理が複雑になるシナリオを単純化するのに役⽴ちます。 アカウント・グルー プは階層構造を持つことができるため、エンタープライズは任意の⼤規模組織を管理するのに役⽴ちます。 エンタープライズをどのような構造にするのかは、使⽤量とコストを分析する⽅法 に基づきます。 請求および使⽤量をどのように追跡 および管理したいのかに応じて、エンタープライズを編成することになります。 © 2022 IBM Corporation 部⾨別に編成されたエンタープライズ たとえば、予算をいくつかのグローバル・チームが共有している組織の場合、部⾨に従ってエンタープライズ 構造をモデル化できます。 この構造では、部⾨ごとに集約された使⽤コストを確認できます。 この他にも、地域別に編成したり、教育機関では研究分野ごとに編成したり、柔軟な構造をとることが できます。
22. IBM Cloud 101 #2 IBM Cloud の IAM を理解(ワカ)る まとめ＆クロージング 22 © 2022 IBM Corporation
23. 23 © 2022 IBM Corporation 本⽇のまとめ • IAMの仕事は、ID 管理とアクセス管理 • 誰が、どのリソースに、どのような操作を⾏えるかを管理 • セキュリティ確保と⽣産性の向上の重要な要素 • IBM Cloud では、リソース・グループの管理に使う • IBM Cloud の ID には、ユーザ / サービス ID がある • アクセス・グループを使うと効率的に管理できる • 多要素認証を使って、よりセキュアなクラウド活⽤を実現 • アクセス管理は、アクセス・ポリシーで実現 • アクセス・ポリシーは、[Subject]+[Target]+[Role]で定義 • [Subject]: ユーザ / サービス ID / アクセス・グループ • [Target]: リソース・グループやサービスなど • [Role]: プラットフォーム・ロールとサービス・ロール • アカウントを階層構造で管理するにはエンタープライズ機能を活⽤ • エンタープライズ機能を利⽤するにはサブスクリプション契約が必要 • アカウント・グループはアカウントの付け替えが可能
24. Question ? 24 © 2022 IBM Corporation
25. 25 © 2022 IBM Corporation 次回の IBM Cloud 101 は︖ IaaS Classic Infrastructure 次回は6⽉中旬に開催予定です。(募集は本⽇から)
26. ご清聴有難うございました IBM Tech/Developer Dojo 101