> ## Documentation Index > Fetch the complete documentation index at: https://docs.livingsecurity.com/llms.txt > Use this file to discover all available pages before exploring further. # サービスアカウント > 組織の API キーおよび OAuth クライアントを所有する連携用 ID を作成し、管理します。 サービスアカウントは、連携に対して付与される名前付きの ID です。API キーまたは OAuth クライアントを所有し、それらの認証情報が使用できる権限を保持するため、アクセスレビューはアカウント単位で実施できます。連携で実行できる操作は、保有する認証情報の数にかかわらず、1 か所で確認できます。アカウント自体は認証情報ではないため、その ID でリクエストを認証することはできません。認証方法の選択については、[認証](/ja/developers/v1/authentication)を参照してください。API キーを使用する連携では、OAuth は不要です。 サービスアカウントは、[Developer Hub](/ja/developers/developer-hub/overview) の **Service accounts** タブから管理します。 ## ワークロード単位でアカウントを設計する すべてを 1 つの広範なアカウントで賄うのではなく、連携またはワークロードごとに 1 つのサービスアカウントを作成してください。たとえば、`reporting-pipeline`、`scim-sync`、`soc-enrichment` のように分けます。ワークロードごとにアカウントを分けることで、権限を最小限に保ち、[リクエストログ](/ja/developers/developer-hub/request-logs)の帰属を明確にし、ほかの連携に影響を与えずに特定の連携のみを無効化できます。 ## サービスアカウントを作成する アカウントが対象とするワークロードを識別できる名前と、その用途を説明する内容を入力します。どちらも一覧やログに表示されるため、将来の管理者がアカウントを区別しやすくなります。 アカウントが認証情報に付与できる権限を選択します。たとえば、`entity:read`、`simulation:read`、`reporting:read` などです。この権限のセットは、そのアカウントで作成されるすべての認証情報の上限となります。認証情報には、これらの権限のサブセットを設定できますが、これを超える権限は設定できません。 ワークロードが現時点で必要とする最小限の権限のみを付与してください。アカウントの権限は後から追加できます。既存の認証情報は、付与済みのスコープを保持します。 名前と権限のセットを確認します。作成後は、アカウントの詳細ページから[API キーを作成](/ja/developers/developer-hub/api-keys)できます。 ## ライフサイクルを管理する * **権限はいつでも編集できます。** アカウントから権限を削除すると、その API キーおよび OAuth アクセストークンで行使できる権限からも削除されます。 * **アカウントを無効化**すると、そのすべての認証情報を通じた API アクセスが停止されます。これは、連携のオフボーディング時や、認証情報の漏えいが疑われる場合に調査を行いながら影響を封じ込める際に有用です。再度有効化すると、有効で期限切れになっていない認証情報は、再び認証できるようになります。 * **アカウントを削除**するのは、連携が廃止された場合です。先に連携を停止し、その認証情報を失効させてください。削除は元に戻せません。 各アカウントの詳細ページには、作成者、作成日時、およびキーが最後に使用された日時が表示されます。これにより、無効化すべき使われていない連携をすばやく見つけることができます。 This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.