APIセキュリティー

2 つの異なるレベルで API を保護することができます。これらのレベルは、API を呼び出すことができるユーザーと、そのユーザーが持つ必要がある許可を制御するのに役立ちます。

API を呼び出すとき、以下の 2 つのレベルのセキュリティーを通過する必要があります。

  1. ユーザー ID、証明書、またはその両方を使用した認証。 ログイン API は、他の API が呼び出される前に呼び出されます。
  2. 許可。アクセス可能な API を検証します。

このセキュリティー手順は、アプリケーション・サーバー・プロセスを通過するあらゆる API 呼び出し用のものです。 デフォルトでは、エージェントおよび統合サーバーには、常に API への全アクセス権限があります。

認証検査をパスすると、承認検査によって、アクセスできる API およびリソースが決定されます。 この許可検査は、ユーザー・インターフェース (UI) セキュリティーを補うものです。 例えば、UI セキュリティーは、ユーザーをリストする画面へのアクセスに役立ちます。 画面でユーザーのリストを生成するには、ユーザーをリストする getUserList API の許可検査に合格しなければならない場合もあります。

許可検査の他の例としては、以下のものがあります。
  • getCommonCodeList API を表示目的で使用する場合は、API の出力から明示的に制限されているユーザー情報を取得できないようにする必要があります。
  • アラートを割り当てる前に getUserList API を呼び出す場合は、ユーザー・パスワードを取得できません。
  • UserHierarchy API を使用してパスワードを変更する場合は、以下のようにします。
    • IsSuperUserを自分で変更できないようにしなければなりません。
    • 他のユーザーの情報を変更することはできません。
    • より多くのユーザー・グループをサブスクライブできないようにする必要があります。これにより、より多くのシステム・アクセス権限が付与されます。

このセキュリティーは、セキュリティー・テンプレート・ファイルを使用して実装されます。 この apisecurity のテンプレート・ファイルは、(デフォルトで) すべての API が制限を受けている入力要素および出力要素を文書化する XML ファイルです。 これらのファイルは、XAPI デプロイメント中に自動的に生成されます (文書生成がオフになっている場合も同様)。

注: サービスは、セキュリティー・ファイルを使用しません。

テンプレートは、入力および出力の許可検査に使用されます。 これらのテンプレートは、正規のテンプレートより優先されます。

例えば、OrganizationCode=#PROHIBITED# と IsSuperUser=#PROHIBITED# の行がある入力テンプレートは、ユーザーが追加でユーザー・グループに加入し、追加のアクセス権を取得することを防止します。

出力テンプレートは、デフォルトの文書ベースのテンプレートが実行するフィルタリングを補います。 要素は、apisecurity ファイルで構成されていないために制限を受けている場合、出力で返されることはありません (文書ベースのテンプレートにある場合も同様)。

注: 入出力の特定の時点で、 multiApi や getPage などの API は、どのエレメントに対しても許可アクセス権限を持っています。 しかし、これらの API に呼び出されるその他の API は、許可検査を受ける必要があります。

API セキュリティーおよびアクセス権レベルへのアクセスは、yfs.properties ファイルの以下のプロパティーで制御されます。 すべての許可失敗は、sci.apisecurity というロギング・カテゴリーに記録されます。

  • api.security.enabled
    • Y (デフォルト) — API のセキュリティーを使用可能にします
    • N — API のセキュリティーを使用可能にしません
  • api.security.mode
    • STRICT — 任意の検証に失敗すると、例外がスローされます。 これは、すべてのアクセス権が正しく構成されている場合、実動システムでは適切です。
    • LAX — 無効な入力をフィルタリングして記録しますが、処理は継続されます。 このフィルタリングでは、不正な入力または出力にもかかわらず、システムによるほとんどの処理が許可されます。一方、ログを記録することによって変更する必要がある場所の特定の役に立ちます。
      注: フィルター操作によってあいまいな動作が生じる場合でも、システムは例外をスローすることがあります。
    • DEBUG — 不正な入力および出力を記録しますが、何もフィルタリングせず、また例外をスローしません。 これは、さまざまなプロセスで必要とされるアクセス権を識別するために、初期開発時にのみ適しています。

セキュリティー・モードを指定しない場合、フィルタリングは行われず、例外はスローされず、許可検査は行われません。 制限されたロギングがあります。

  • api.security.override. apiName.mode

    個別の API のアクセス権をオーバーライドするには、この設定を使用します。 このプロパティーは、api.security.mode と同じ値を使用します。

  • api.security.smc.enabled
    • Y- Applications Manager の API セキュリティーを有効にします。
    • N (デフォルト)- Applications Manager の API セキュリティーを有効にしません。
  • api.security.console.enabled
    • Y — Application Console の API のセキュリティーを使用可能にします
    • N (デフォルト) — Application Console の API のセキュリティーを使用可能にしません

アップグレードするとき、最初にこの機能を使用不可にし、プロパティーですべてのアクセスを付与する必要があります。 アップグレードされたシステムで、アクセス権を定義してテストするように、一度に 1 つの API のセキュリティーを使用可能にして、この機能を段階的に導入できます。 使用可能にされると、システム・ユーザー・グループのみが API へのアクセス権を付与されます。他のすべてのカスタム・ユーザー・グループには、適切なアクセス権を付与する必要があります。 ユーザー・グループの権限については、 組織のモデル化についてを参照してください。