人ではなくアプリケーションで使用されるユーザーを作成する場合、どのような注意が必要ですか？
webservices bus にアクセスする必要があるいくつかのアプリケーションがあります。バスにアクセスする独自のアプリケーションは、そのバス上のWebサービスを使用して認証しますが、この場合、サードパーティのアプリケーションがバス内の一部のWebサービスにアクセスする必要があります。
これらのサードパーティアプリケーションは、LDAP（ Oracle OID ）で認証する必要があります。認証が必要なアプリケーションごとにユーザーとパスワードを作成する必要があります。
これらのサードパーティアプリケーションをWebサービスバスで認証するためのより安全な方法はありますか？
OIDでこれらのユーザーを作成する場合、どのような注意が必要ですか？
人ではなくアプリケーションで使用されるユーザーを作成する場合、どのような注意が必要ですか？
識別と追跡が重要になりますが、驚くほど困難です。
まず、ディレクトリ内のアカウントにタグを付けて、非ユーザーIDとして識別できるようにします。
ユーザー以外の各アカウントは、アクセスするシステムのセキュリティ保護を担当するアカウント所有者に関連付ける必要があります。所有者のIDを非ユーザーIDのディレクトリエントリに保存します。これにより、後でこれらの情報を探し出す場合、誰に連絡する必要があるかがわかります。所有者は従業員の昇進や離職などを行ったり来たりするので、従業員IDと一緒に行くには部門や他の組織のタグが必要になる場合があります。ここでグループメンバーシップが役立ちます。また、従業員が退職すると、ディレクトリアカウントが削除され、不明なIDが役に立たなくなる可能性があります。名前は、少なくとも他の人が追跡を手助けできる人です。
アカウントが関連付けられているマシンを知ることも役立つ場合があります。その情報もディレクトリに保存してください。
アカウントやマシンなどをリクエストするための要件を入力する正式なリクエストシステムがある場合、リクエスト番号をディレクトリエントリに保存します。ただし、リクエスト追跡システムは変更される可能性があり、5年前に発行された追跡番号に関連する情報は利用できなくなる可能性があることに注意してください。所有者とマシンの情報も記録に残すことをお勧めします。
アカウントの正式なレビュープロセスがまだない場合は、それを実装すると、ディレクトリに大量の非ユーザーアカウントが作成されることを考慮してください。このデータは、レビュー担当者を特定するのに役立ちます（システム所有者は、適切かどうかを定期的に確認する必要があります）。レビューデータを記録とともに保管することを検討してください。監査人に提供するために、ディレクトリの「最後にレビューされた/によって」情報を保持することもできます。
この情報を保持する主な理由は、妥協の場合です。応答フェーズでは、最小限の労力で、パスワードを変更し、システムをスキャンし、すばやく追跡できるように、アカウントに関連付けられている人物をすばやく特定できる必要があります。少なくとも調査がアクティブな間は、システム所有者に警告せずにこのアクティビティを実行する必要がある場合があることに注意してください。また、調査員にレビュー情報を提供する必要がある場合もあります。妥協が内部のソースから発生する可能性があることは悲しい現実です。
残りの質問に答えるには、（JavaScriptのrandom（）ではなく）暗号学的に強力なパスワードジェネレータを使用して、長いパスワードを生成する必要があります。パスワード管理ツールを使用して、人間を介さずにこれらのアカウントとパスワードを割り当てることができる場合は、さらに優れています。 LDAPサーバーと連携してこれを行う商用システムがあります（Oracleショップなので、このようなシステムを販売しているので、アカウント担当者に確認する必要があります）。
一般に、自動化のために作成されたユーザーと実際の人のために作成されたユーザーとの間に大きな違いはありません。それでも、各ユーザーが必要なアクセスのみを制限する必要があります。
信頼できるリソースへのサードパーティのサービスアクセスをセグメント化する方法について考えるのは少しあいまいです。通常、1人のアカウントは1つだけであり、ユーザーごとに複数のアカウントを作成することはありません（ただし、これにはいくつかの例外があります）。しかし、「サービス」はさまざまな方法で考えることができます。これをどのように描くかを決定できるのはあなただけであり、単一のサービスと考えるもののさまざまな部分にさまざまなレベルのアクセスが必要かどうかを判断できます。
例として、postfixと呼ばれるよく知られているメールサーバーがあります。高レベルでは、postfixは単一のサービスと考えることができます。下位レベルでは、内部の各サービスを構成する複数のプロセスが実際に設計されています。各プロセスには、ジョブを完了するために必要な最小限の特権があります。
サードパーティのソフトウェアを使用すると、「最小限の特権」で物事を実行できる場合とできない場合があります。しかし、自動化をセットアップする際には、実際の人に対応する場合にはそれほど重要ではない、設計上の重要な考慮事項です。
- 他のコメンテーターは、LDAPの代わりに証明書を使用することを提案しました-しかし、2つの認証メカニズムを使用することは、簡単に行うことができない場合はお勧めしません。 1つの認証システムがあれば、不適切な実装の可能性が低くなります。
- 強力なパスワードには、「UUID-type 4」ジェネレータアルゴリズムを使用します。これにより、ランダムな文字列があなたに合うようになります（推測はできません）。
- アプリケーションで使用されていないユーザーは、そのユーザーの完全な権限を持っているという弱点がありますが、アクセス権を持つ誰でも制御できます（そのため、元従業員は引き続きアクセスできる可能性があります）-このようなアプリケーションへのアクセス権があることを確認してください管理されている（それらのアクセス許可と共に-それらが機能するのに十分なアクセス許可のみを与える）。また、パスワードの有効期限も慎重に管理してください。アプリケーションにそのような有効期限オプションが組み込まれておらず、有効になっている場合、予期しないときにアプリケーションが機能しなくなる可能性があります。