ユーザーリスクを軽減
ガバナンスとは、許容できるリスク(リスク許容度に応じて)で価値を最適化することです。ユーザーリスクは、 Mendix ガバナンス価値フレームワーク。ユーザー リスクを軽減するには、プラットフォームのアプリケーションを開発する人々とアプリのエンド ユーザーの ID とアクセスを管理する必要があります。
私たちが特定したユーザーには 3 つのカテゴリがあります。
- プラットフォームユーザー – これらは、ローコード アプリケーションを開発するか、これらの開発者と協力する従業員です。
- 拡張された労働力 – これは、実装パートナーの従業員であるプラットフォームユーザーの特別なカテゴリであり、 Mendix プラットフォームユーザーとしての開発努力。
- アプリケーションユーザー – これらはあなたが構築したアプリケーションのエンドユーザーです Mendix. アプリケーションの構築に使用された技術を知らない場合もあります。アプリケーションユーザーは、アプリケーションに関するフィードバックを提供したり、コラボレーションしてポートフォリオをさらに強化したりしたい場合に、プラットフォームユーザーになることもあります。 Mendix 分野の様々なアプリケーションで使用されています。
コントロールプラットフォームのユーザーリスク
従業員に評価を任せるにはどうすればいいでしょうか? Mendix プラットフォームを構築したり、アプリケーションの開発を開始したりしますか?
従業員は自ら参加することで Mendix 開発プラットフォームにサインアップするだけで Mendix ウェブサイト。必要なのは以下のとおりです。
- ビジネス用メールアドレスを確認する
- パスワード(必要な場合)を選択し、
- いくつかの質問に答えて、キャリアのスタートガイドを受け取ってください。 Mendix 開発者。
契約する必要はありません Mendix まず、評価したい場合も同じサインアッププロセスが適用されます。 Mendix プラットフォームまたはローコード開発をすでに行うことを決めている場合 Mendix.
この Mendix プラットフォームは、同僚と同じメールドメインを持つユーザーを認識し、共同作業を容易にします。プラットフォーム ユーザーはお互いを招待することもできるため、招待リンクをクリックすると、オンボーディングがさらに簡単になります。
参照してください スタートガイド のセクションから無料でダウンロードできます。
従業員はどのようにしてログインできますか? Mendix プラットフォーム?
この Mendix プラットフォームには、従業員がオンラインにサインインできるようにするIDサービスが含まれています。 Mendix プラットフォームと統合開発環境(IDE)と呼ばれる Mendix スタジオプロ。
次のいずれかの方法でプラットフォーム ユーザー認証を設定できます。
- サインアップ時に作成されたユーザー定義のパスワード:これはデフォルトのメカニズムであり、これにより、迅速かつ簡単に Mendix プラットフォームを提供します。 Mendix プラットフォームのパスワードに一般的なパスワードの複雑さのルールを適用し、 パスワードの有効期限を設定するその後、開発者はパスワードを変更する必要があります。
- アイデンティティ連携 Mendix プラットフォームと企業の ID プロバイダー (IdP): これにより、プラットフォーム ユーザーにエンドツーエンドの SSO エクスペリエンスを提供できます。 Mendix プラットフォームのSSO機能はBYOIDP(Bring-Your-Own-IDentity-Provider)と呼ばれます。この機能には スタンダードまたはプレミアム プラットフォーム ライセンス。Studio Pro への各 SSO ログインでは SSO 用のシステム ブラウザが使用されるため、IdP の条件付きアクセス機能 (信頼できるデバイスの確認など) を適用できます。
- SAP BTP認証情報または Siemens IdPの Siemens Xcelerator のお客様の場合: これにより、ユーザーがさらに別の資格情報セットを持つことができなくなります。
どのように Mendix プラットフォームは多要素認証をサポートしていますか?
多要素認証(MFA)はセキュリティをさらに強化し、侵害されたアカウントからの攻撃を防ぐために重要です。多くの企業は、多要素認証の対象範囲に、 Mendix プラットフォームを提供します。
プラットフォームSSOを有効にすることは、プラットフォームユーザーにMFA(または2FA、多くの企業は認証にはXNUMX要素で十分だと考えている)を強制するための推奨されるアプローチです。これにより、IdPの範囲が拡張されます。 Mendix プラットフォームを導入し、すでに導入されている MFA プロセスを活用します。
さらに、 Mendix プラットフォームは機密性の高いアクティビティに対して2要素認証(XNUMXFA)を強制します。この認証手順は、本番環境アプリケーションを手動でデプロイするたびに必要です。 Mendix クラウド。 Mendix プラットフォームには、SMSログインコードと時間ベースのワンタイムパスワード(TOTP)が含まれています。TOTPは、GoogleまたはMicrosoftの認証アプリと互換性があります。プラットフォームユーザーは、 Mendix プラットフォームは、ビジネス用メールアドレスに送信された確認リンクを使用するセルフサービスメカニズムを介して機能します。
どのように Mendix プラットフォームでは、プラットフォーム ユーザーの権限を管理できますか?
Mendix の定義を支持する Mendix 管理者 委任管理の概念に従ってユーザーに権限を割り当てることができる。1人以上の Mendix 他のプラットフォーム ユーザーに付与される権限を制御できる管理者。
この コントロールセンター 行政の中心地であり、 Mendix アプリの状況、メンバー、クラウド環境を一目で把握できます。コントロールセンターでは、 Mendix 管理者 チーム メンバーのアクティビティを表示でき、次の管理タスクを実行できます。
- 社内または社外のステータスを含む、会社のプラットフォームユーザーの概要を取得します。 Mendix 認定レベルとアクセスできるアプリ。
- セキュリティ上のリスクであると特定されたメンバーを非アクティブ化します。
- アプリの作成者や最終更新日など、会社のすべてのアプリケーションの概要を取得します。
さらに、 Mendix プラットフォームはAPI( プロジェクト API) を使用して、ユーザーをスクラム マスターとして追加したり、個々のアプリ プロジェクトから自動的に削除したりできます。
開発者がアクセスし続けるのを防ぐにはどうすればいいですか? Mendix 彼らが私の会社を去った後のプラットフォームですか?
この Mendix コントロールセンターでは Mendix 管理者は 無効にする プラットフォームユーザー。これにより、そのユーザーは Mendix プラットフォーム サービスまたはプラットフォーム API を使用します。
アイデンティティフェデレーションを設定している場合 Mendix プラットフォームと企業のIdP(プラットフォームSSO)をブロックすると、IdPで開発者をブロックすると、 Mendix プラットフォーム。このようにして、中央のアイデンティティガバナンスプロセスを、 Mendix プラットフォームを提供します。
開発者が私の開発にどのように貢献するかを管理するにはどうすればいいですか? Mendix アプリ?
この Mendix プラットフォームには、さまざまな開発ロールがあり、 Mendix ポータル。
開発中のアプリごとに、独自のアプリチームを編成し、 アプリチームの役割 チーム メンバーに通知したり、追加の開発者をアプリ チームに招待したりできます。
弊社のプラットフォーム ユーザーの現在の認定レベルはどの程度ですか?
ガバナンスの鍵の一つは、従業員が適切に訓練されていることを確認することです。 メンバー概要 コントロール センターには、アプリ開発にアクセスできるすべてのプラットフォーム ユーザーと、その現在の認定資格が一覧表示されます。
どの特権アカウントが Mendix 持ってる?
特権アカウントの管理はサイバーセキュリティの鍵です。なぜなら、データ侵害の大半は特権アカウントに関係しているからです。 Mendix プラットフォームには、 Mendix 権利。これらの Mendix 管理者(または単に「Mendix 管理者は組織レベルでさまざまな Mendix あなたの会社が作成したアプリ。 Mendix 管理者は Mendix コントロール センターでは、ユーザーをアクティブ化または非アクティブ化したり、プロジェクト ロールを編集したり、アプリ アクセス グループを設定したり、会社のテナント レベルで設定を管理したりできます。
開発するすべてのアプリで Mendix 技術連絡先 が割り当てられます。技術担当者はアプリの最初の連絡先であり、展開設定を制御します。
導入されるすべてのアプリについて Mendix 雲、 Mendix 「ローカル」を作成する 管理者 ユーザー、 管理者、アプリケーションの開発者によって作成された管理ユーザー ロールを取得します。さらに、アプリケーション ロジックによって、他のエンド ユーザーにローカル管理者ロールを割り当てることもできます。開発者は、この特定の管理ユーザー ロールに含まれる権限を完全に制御できます。たとえば、管理者権限がまったくない場合があり、アクセス ガバナンス上の理由でローカル管理者ユーザーを使用したくない企業の場合は、このロールを「空」のユーザー ロールにすることもできます。
拡張労働力リスクの管理
起業したばかりの企業や、特定の専門知識を必要とする企業は、フリーランサーを活用して開発者の労働力を拡大することを検討するかもしれません。 Mendix 実施パートナー、または Mendix 専門サービス。他の企業では、一部のアプリの開発とメンテナンスをパートナーにアウトソーシングすることを選択する場合があります。
社内の外部開発者をどのように管理すればよいですか?
外部の従業員の認証方法を制御したい場合は、会社のIdP(つまり、 [メール保護]) を外部従業員に付与します。これにより、元従業員の自動的な非アクティブ化を含め、外部従業員を通常の従業員と同じ方法で管理できます。
それが前提条件でない場合は、プロジェクトロールで「招待」権限を持つ人がプロジェクトに外部メンバーを招待することが可能です(例: [メール保護]) をアプリ プロジェクトに追加すると、このユーザーは各自の会社の認証方法で認証されます。
社内の従業員とほぼ同じように、コントロール センターでは、他のドメインの外部メンバー、彼らが共同作業しているプロジェクト、彼らが取得した最高レベルの認定の概要を確認できます。
開発チームに所属しなくなった場合は、プロジェクトから削除できます。どのプロジェクトにも参加しなくなった場合、外部メンバー リストに表示されなくなります。
実装パートナーとアプリケーションを共同作業するにはどうすればよいですか?
開発をアウトソーシングすることを選択した場合 Mendix アプリケーションを実装パートナーに渡す場合、推奨されるアプローチは、自分でアプリ プロジェクトを作成し、そのプロジェクトでパートナーと協力することです。これにより、IP を完全に制御でき、プロジェクトを管理する最適な方法です。また、従業員が所有権を取得したり、別の実装パートナーに切り替えたりすることもできます。
パートナーに、これらのプロジェクトで協力するために必要な適切な権限を与えることができます。プロジェクトへの貢献が終了したら、プロジェクト チームから削除できます。アプリ プロジェクトとパートナーが行ったすべての貢献はプロジェクトに残ります。
あるいは、パートナーがプロジェクトを作成し、そのプロジェクトで共同作業するように招待することも可能です。その場合、パートナーの貢献が終了したら、独自のプロジェクトを作成し、パートナーが開発したアプリをインポートすることで所有権を取得できます。
アプリケーションユーザーリスクの制御
アイデンティティとアクセス管理(IAM)の一般的な定義を言い換えると、アプリケーションユーザーリスクの制御とは、適切なアプリユーザーが適切なアプリケーションにアクセスできるようにすることであると言えます。 Mendix 適切なユーザーロールを持つアプリケーションを適切な理由で提供します。アプリユーザーとは、 Mendix アプリケーションには、エンドユーザーと特権ユーザー (管理者ユーザーとも呼ばれます) の両方が含まれます。
次の図は、典型的な企業対従業員(B2E)で使用されるIAM機能を示しています。 Mendix アプリケーション。
ユーザーは私のサイトにアクセスするときにどのように認証されるのか Mendix 応用?
この Mendix プラットフォームは、あなたのユーザーを認証するためのさまざまな可能性を提供します Mendix 応用。
最初の可能性は アプリケーションユーザーを認証します。訪問者に 匿名アクセス アプリケーションの制限された部分にアクセスできるようにします。特に、(潜在的な) 顧客や消費者を対象としたアプリケーションを構築している場合は、そのようなユーザーを登録ユーザーに変換する前に、制限された機能へのアクセスを許可することをお勧めします。
2つ目の可能性は、アプリケーションユーザーをアプリケーション内でローカルに認証することです。これは、エコシステムやアイデンティティプロバイダー(IdP)で既に持っているアイデンティティとは完全に独立しています。ユーザー名とパスワードによるログインは、 Mendix アプリケーション(参照 ログイン動作 によって提供される Mendix パスワードリセット機能は、 パスワードをお忘れですか モジュールをビルディングブロックとして使用します。このようなローカル認証は、MFAモジュールを使用して強化できます。 Mendix マーケットプレイスまたはカスタムロジックでも使用できます。
3 番目で最もよく使用される認証方法は、シングル サインオン (SSO) を介して ID プロバイダー (IdP) として機能する外部アプリケーションにユーザー認証を委任することです。
どのように Mendix ローコード アプリケーションでシングル サインオン (SSO) をサポートしていますか?
シングルサインオンは、アプリケーションとアイデンティティプロバイダ(IdP)の両方の機能に基づいたユーザーエクスペリエンスです。 Mendix プラットフォームにより、シチズンデベロッパーでもSSO対応アプリケーションを構築できます。SSOは通常のWebアプリケーション、プログレッシブWebアプリケーション、ネイティブモバイルアプリケーションでサポートされており、適切なSSOモジュールを使用して有効化できます。 Mendix 市場。 Mendix 完全な プラットフォームサポート これらのモジュールについて。
SSO機能は、どの導入モデルにも限定されません。 Mendix 上のアプリケーション Mendix クラウド、パートナー クラウド、独自のプライベート クラウド、さらにはオンプレミスでも、SSO がサポートされています。 MendixのSSO機能は、によって提供またはホストされるIDサービスに依存しません。 Mendix.
Mendix 今日の SSO のオープン スタンダードである SAML 2.0 および OpenID Connect をサポートします。 Mendix 開発者は適切なモジュールをダウンロードすることができます(つまり OIDC SSO or SAML)から Mendix マーケットプレイスにこれらを組み込んで、 Mendix アプリケーションで必要なSSO機能を利用するには、ネイティブアプリの場合、 モバイルSSO モジュールが必要です。オープンスタンダードに基づくSSOに加えて、 Mendix また、SAP Business Technology Platform (BTP) 上で実行されるアプリケーションの SSO もサポートします。 Mendix 〜を提供する SAP BTP 用 XSUAA コネクタ SAP ID インフラストラクチャを使用した SSO 用。
多要素認証を導入するにはどうすればいいですか? Mendix アプリケーション?
多要素認証(MFAまたは2FA)の最も一般的なアプローチは、アプリケーションでSSOを有効にし、ユーザーのログイン時にIdPにMFAを適用させることです。 Mendix アプリケーションでは、マーケットプレイスで利用可能なモジュールの 1 つを使用して、デフォルトのユーザー名とパスワードの検証を 2 番目の要素で拡張できます。
どのIDプロバイダソリューションを利用できますか? Mendix アプリケーション?
あなたは統合することができます Mendix ほとんどのアイデンティティプロバイダソリューション(IdP)でアプリケーションを統合します。既存の Mendix 顧客は、アプリケーションを Microsoft の Entra ID (旧称 Azure AD)、Auth0、Ping、ForgeRock、AWS Cognito、Google、Salesforce、Apple、Okta、Ping、SAP Cloud Identity Services、Facebook、LinkedIn、KeyCloak、AWS IAM Identity Center と統合しています。
一般的なオープンスタンダード(OpenID Connect、SAML v2.0など)をサポートするテクノロジーであれば、統合することができます。たとえば、SAMLモジュールのより高度な機能により、より安全な「アーティファクトバインディング」を利用して、より高いレベルのセキュリティを要求するIdPとの統合が可能になります。たとえば、オランダの顧客は、これを使用して、欧州のアイデンティティ管理標準に基づくスキームである政府規制のIAMインフラストラクチャDigiDとeHerkenningにアプリケーションを統合しています。 eIDAS規制.
アプリケーションのユーザー ロールを定義するにはどうすればよいですか?
Mendix アプリは完全な柔軟性を提供します Mendix 開発者はモジュール ロールを利用して、任意の方法でユーザー ロールを定義および実装できます。
ユーザーロールは複数のモジュールロールを集約し、データ、ページ、マイクロフロー(ロジック)へのアクセス権を与えます。すべてのユーザーロールは1つ以上のモジュールロールで構成でき、モジュールロールは複数のユーザーロールに含めることができます。 Mendix マーケットプレイス Mendix 開発者は、すぐに使用できるモジュールロールを、自分のユーザーロールに含めることを選択できます。 Mendix アプリケーション。
アクセス管理に関係するのはユーザー ロールのみです。アプリケーションのエンド ユーザーは、自分のユーザー ロールのみを認識します。モジュール ロールの概念は、アプリケーション開発者にのみ関係し、アプリケーション内部のものです。
これに関する詳しい情報は アプリのユーザー ロールを定義するにはどうすればよいですか? セキュリティ モデル ガイドのセクション。
アプリ内のユーザーにユーザーロールはどのように割り当てられますか?
あらゆる Mendix アプリケーションには 1 つ以上のユーザー ロールがあり、複数の方法でアプリケーション ユーザーに割り当てることができます。
最も シンプルな ユーザーの役割を割り当てる方法は、 管理モジュール アプリケーションで、管理者ユーザーがアプリケーション ユーザーにユーザー ロールを手動で割り当てるようにします。
ユーザー ロールを割り当てる最もよく使用される方法は、アイデンティティ プロバイダー (IdP) を活用することです。アプリケーション ユーザーがシングル サインオン (SSO) 経由でアプリケーションにログインすると、通常、IdP はユーザーに関する情報を提供し、この情報を使用してユーザーにユーザー ロールを自動的に割り当てることができます。SSO モジュールには、これを行うためのいくつかのデフォルトが付属しており、ローコード開発者は、ユーザー ロールを割り当てるための独自のカスタム ロジックを簡単に実装できます。このようなカスタム ロジックは、IdP によって提供される情報のセマンティックな解釈であり、使用されるプロトコルと機能に応じて、アサーション、クレーム、属性、スコープ、およびロールの形式を取ることができます。
後者のアプローチには、自動化と承認の集中管理という明らかな利点があります。大規模な組織では、特に多数のアプリケーションとアプリケーション ユーザーを抱える場合、Joiner-Mover-Leaver プロセスを自動化する必要があります。
IdP 統合なしでマルチアプリケーション ソリューションに SSO エクスペリエンスを提供するにはどうすればよいですか?
ビジネス対従業員(B2E)ソリューションを構築する場合、通常はSSO対応アプリを企業のアイデンティティプロバイダ(IdP)と統合することでシングルサインオン(SSO)を実現します。ただし、ビジネス対消費者(B2C)またはビジネス対企業(B2B) ソリューションでは、外部 IdP との統合が不可能、望ましくない、またはコストがかかりすぎる可能性があります。
「シンプルな」アプローチは、単一の Mendix ローカル ユーザー ログインを備えたアプリケーション。ソリューションの複雑さによっては、ソリューションの保守性を向上させるために、マルチアプリケーション ソリューションを構築することが必要になる場合があります。その場合、複数のアプリケーションにわたってアプリケーション ユーザーに SSO エクスペリエンスを提供するという課題に直面します。 Mendix 次のようなソリューションを構築するのに役立ちます Mendix アプリケーションは、アプリケーション ユーザーがログインするポータル アプリケーションとして機能します。このポータル アプリケーションは、他のアプリケーションの IdP として機能する中央アプリケーションになります。
これを行うには、 Mendix マーケットプレイスは、いわゆる OIDC プロバイダー 中央ポータル アプリケーションに含めることができるモジュール。アプリケーション ユーザーは、ポータル アプリケーションにサインインし (たとえば、ローカルのユーザー名とパスワードを使用)、接続されている他のアプリケーションに移動して、問題なくアクセスできます。
ユーザーを作成するにはどうすればいいですか? Mendix アプリケーションですか? また、それらを無効にしたり削除したりするにはどうすればいいですか?
アプリケーション ユーザーのユーザー プロビジョニングまたはオンボーディングを実行するには、さまざまなアプローチから選択できます。
この シンプルな アプローチとしては、ローカルの「管理者」ユーザーにアプリ内でユーザーを手動で作成してもらうことです。 管理モジュール、で利用可能 Mendix マーケットプレイスは、そのようなソリューションを構築するのに役立ちます。
ユーザーは、いわゆるジャストインタイム (JIT) ユーザー プロビジョニングによって作成することもできます。アプリで SSO が有効になっている場合、初めてサインインするユーザーは、アイデンティティ プロバイダー (IdP) によって提供されるユーザー情報に基づいて、アプリ内に自動的に作成されます。ローコード開発者は、SSO モジュールに含まれるデフォルトのユーザー プロビジョニング ロジックを使用することも、カスタム ロジックを作成してこれを行うこともできます。
JITユーザープロビジョニングを使用すると、IdPはアクセスロジックを適用して特定のユーザーへのアクセスを拒否できるため、アプリで作成されるユーザーを制御できます。JITユーザープロビジョニングは柔軟で実装が簡単で、手動のユーザープロビジョニングを回避できます。欠点は、このSSOベースのメカニズムではユーザーを非アクティブ化したり、アプリから削除したりできないことです。 Mendix 分野の様々なアプリケーションで使用されています。
アプリケーションからユーザーを非アクティブ化または削除するには、2つのオプションがあります。1つ目は、ローカルユーザー管理を使用して、ローカルの「管理者」が管理モジュールでローカルにユーザー管理を行うことです。2つ目のより良いオプションは、 Mendix アプリケーションをIDPと連携させ、その統合によって作業を行います。アプリケーションは、LDAPプロトコルを介してオンプレミスのIdPと統合できます。より現代的なアプローチは、SCIM統合を使用することです。SCIMは、System for Cross-domain Identity Managementの略語です。これは、Entra ID、Okta、PingなどのほとんどのIdPソリューションでサポートされているオープンスタンダードです。 Mendix マーケットプレイスでは LDAP モジュール ローコード開発者が使用できる SCIM モジュール。
IAM の速度低下を招くことなく簡単にスケーリングするにはどうすればよいでしょうか?
多くの開発を計画している場合は Mendix アプリケーションでは、特定のタスクを繰り返す必要性を回避または最小限に抑えるにはどうすればよいでしょうか。IAM のドメインでは、次の操作を実行できます。
- まず、選択した IAM モジュールを使用してスターター テンプレートを作成します。
- 次に、IAMモジュールをカスタマイズしないようにしてください。カスタマイズバージョンが必要な場合は、 プライベート Mendix 市場 スターターテンプレートもあります。また、 Mendix カスタマイズを製品化できるかどうかは、カスタマーサポートマネージャー(CSM)を通じて製品管理に問い合わせてください。製品化されると、IAMモジュールの新しいバージョンがリリースされても、カスタマイズを再実装する必要はありません。 Mendix.
- カスタムユーザープロビジョニングやカスタム認証ロジックが必要な場合は、それらのカスタムマイクロフローを別のカスタムIAMモジュールに配置し、開発者に配布することができます。 プライベート Mendix マーケットプレイス およびスターター テンプレート。このようなカスタム ロジックを再利用すると、カスタマイズの作業とメンテナンスの重複を防ぐことができます。
- IAM モジュールの設計時および/またはデプロイ時の構成の可能性を使用します。パイプラインは、アプリを 1 つのステージング環境から次のステージング環境に移動し、適切なテストまたは本番環境の IdP に自動的に接続できます。
- SSOブローカーソリューションの作成を検討してください。アプリとIdP間のSSOの設定には手動の手順が必要になる場合があり、手順によってイノベーションが遅れる可能性があります。SSOブローカーソリューションを使用すると、パイプラインが自動的に登録されます。 Mendix SSOブローカーでアプリケーションを統合し、SSOブローカーとIdP間の単一のSSO接続を活用します。SSOブローカーは、 OIDC プロバイダー モジュール.