サービスアカウントとは？ | Silverfort 用語解説

サービスアカウントとは、様々なソフトウェアアプリケーション、システム、またはサービス間の通信や相互作用を可能にするために特別に作成される、人間以外のユーザーアカウントのことです。

取消ユーザーアカウント人間のユーザーに関連付けられるサービスアカウントとは異なり、サービスアカウントはアプリケーションまたはサービスのIDと認証を表すものです。これらは、アプリケーションが他のシステム、データベース、またはリソースと認証およびやり取りするための手段として機能します。

サービスアカウントの主な特徴

サービスアカウントユーザーアカウントとは異なるいくつかの重要な特徴を備えています。まず、人間ユーザーが使用するものとは別の、固有の識別子と認証情報が割り当てられます。これにより、安全で独立した認証アプリケーションとサービスの。

さらに、サービスアカウントには通常、それが代表するアプリケーションまたはサービスの特定の要件に基づいて、制限付きまたは上位の権限が付与されます。セキュリティを確保するためにアクセス権限が制限されているサービスアカウントもあれば、特定の管理タスクを実行したり、機密データにアクセスしたりするために上位の権限が付与されているサービスアカウントもあります。

サービスアカウントは多くの場合、自動化機能と統合機能を備えており、異なるシステムやアプリケーション間のシームレスな通信と連携を可能にします。これらのアカウントは、さまざまなITプロセスを自動化したり、スケジュールされたタスクを実行したり、外部サービスやクラウドプラットフォームとの統合を容易にしたりすることができます。

サービスアカウントとユーザーアカウントの違い

サービスアカウントとユーザーアカウントの違いを理解することが重要です。ユーザーアカウントは人間のユーザーに関連付けられ、対話型セッションを目的としていますが、サービスアカウントはシステム間またはアプリケーション間の通信用に設計されています。非人間的なアイデンティティ.

ユーザーアカウントは、人間がITシステム内でファイルへのアクセス、電子メールの送信、アプリケーションとのやり取りなどの操作やタスクを実行する必要がある場合に利用されます。一方、サービスアカウントはアプリケーションやサービス自体を表し、それらのアプリケーションやサービスに代わって認証、認可、および操作を実行するために使用されます。

サービスアカウントは、バッチ処理、バックグラウンドタスク、クラウドサービスとの連携など、継続的かつ自動化された操作が必要なシナリオにおいて特に有効です。サービスアカウントを利用することで、組織はセキュリティを強化し、効率性を向上させ、ITシステムの円滑な運用を確保できます。

サービスアカウントのユースケース

サービスアカウントは非常に汎用性が高く、ITシステム内のさまざまなシナリオで活用できます。

データベースサービスアカウント：これらのサービスアカウントは、データベース管理システム（Microsoft SQL Server、Oracle Databaseなど）や特定のデータベースインスタンスを実行するために使用されます。データベースサービスに必要な権限とアクセス権限を付与するために作成されます。
Webアプリケーションサービスアカウント：Internet Information Services（IIS）やApache Tomcatなどで実行されるWebアプリケーション用に作成されるサービスアカウントです。これらのアカウントは、アプリケーションプール、Webサービス、およびWebアプリケーションのホスティングに関連するその他のコンポーネントを管理するために使用されます。
ファイル共有サービスアカウント：ネットワーク上のファイル共有やファイルサーバーへのアクセスを提供するために作成されるサービスアカウントです。組織内の共有ファイルやフォルダへのアクセスを認証および承認するために使用されます。
メッセージングサービスアカウント：Microsoft Exchange Serverなどのメッセージングシステムが電子メールサービスを管理・運用するために使用するサービスアカウントです。これらのアカウントは、電子メールメッセージの送信、受信、処理などのタスクを処理します。
バックアップサービスアカウント：バックアップソフトウェアまたはサービス用に作成されるサービスアカウントです。これらは、スケジュールされたバックアップの実行、バックアップエージェントとの連携、およびバックアップストレージへのアクセスに使用されます。
アプリケーション統合サービスアカウント：異なるアプリケーションまたはシステム間の統合を容易にするために作成されるサービスアカウント。これらのアカウントは、アプリケーション間で通信またはデータ交換を行う際の認証および認可に使用されます。

サービスアカウントのメリット

サービスアカウントには、ITシステムの全体的な効率性とセキュリティ向上に貢献するいくつかの利点があります。主な利点を3つご紹介します。

セキュリティと説明責任の向上

サービスアカウントは、アプリケーションとサービスに個別の ID を提供することでセキュリティを強化します。固有の識別子と認証情報を使用することで、組織はアクセス制御をより適切に管理し、最小特権の原則また、サービスアカウントは、組織がアプリケーションによって実行されたアクションを追跡および監査できるようにすることで、説明責任の強化にも貢献し、インシデント調査やコンプライアンス活動を支援します。

管理とメンテナンスの効率化

サービスアカウントの管理を一元化することで、組織は管理業務を効率化できます。サービスアカウントは必要に応じて簡単にプロビジョニング、変更、取り消すことができるため、個々のユーザーアカウントの管理に伴う管理負担を軽減できます。さらに、自動化と標準化されたプロセスにより、組織はITエコシステム全体でサービスアカウントの一貫性のある効率的な管理を確保できます。

システムパフォーマンスと信頼性の向上

サービスアカウントは、システムのパフォーマンスと信頼性の向上に貢献します。サービスアカウントは自動化機能を備えているため、タスクを迅速かつ一貫して実行でき、手動による介入とそれに伴う遅延を削減できます。ITプロセスを自動化することで、組織は応答時間を短縮し、ダウンタイムを削減し、システム全体の信頼性を向上させることができます。サービスアカウントは、負荷分散とリソース利用の最適化にも役立ち、システムパフォーマンスをさらに向上させます。

サービスアカウントの例を教えてください。

サービスアカウントの一例として、Google Cloud Platform（GCP）サービスアカウントが挙げられます。GCPサービスアカウントは、GCP上で実行されるアプリケーションやサービスを認証するために使用されます。これにより、アプリケーションやサービスは、Google Cloud StorageやGoogle BigQueryなどの他のGCPリソースと連携できるようになります。

例えば、Google Cloud Storageに保存されているデータにアクセスする必要があるアプリケーションをGCP仮想マシン（VM）上で実行する場合、GCPサービスアカウントを作成し、適切な権限を割り当てます。VM上で実行されているアプリケーションは、そのサービスアカウントの認証情報を使用してGoogle Cloud Storageに認証し、データにアクセスします。

さらに、サービスアカウントは、API、データベースなど、他のサービスへの認証にも使用できます。

サービスアカウントの種類にはどのようなものがありますか？

サービスアカウントには、その目的と範囲に基づいてさまざまな種類があります。一般的な3つの種類を以下に示します。

ローカルサービスアカウント

ローカルサービスアカウントは、単一のデバイスまたはシステムに固有のものです。これらはシステム上でローカルに作成および管理され、その特定のデバイスに限定されたサービスやプロセスを実行するために使用されます。ローカルサービスアカウントは通常、システムサービスに関連付けられており、複数のシステム間で共有されることはありません。

ネットワークサービスアカウント

ネットワークサービスアカウントは、他のシステムやリソースと連携する必要のあるネットワークサービス向けに設計されています。これらのアカウントはローカルサービスアカウントよりも範囲が広く、ネットワーク内の複数のシステムで使用できます。ネットワークサービスアカウントは、サービスが異なるシステム間で認証を行い、リソースにアクセスする際に、一貫したIDを維持するための手段を提供します。

マネージドサービスアカウント（MSA）

マネージドサービスアカウントは、マイクロソフトが導入した機能です。 Active Directoryこれらは、Windows システム上で実行されるサービス専用に作成されたドメインベースのアカウントです。マネージドサービスアカウントは、パスワードの自動管理、管理の簡素化、およびセキュリティの向上を実現します。これらは特定のコンピューターまたはサービスに関連付けられており、ドメイン内の複数のシステムで使用できます。

組織のITインフラストラクチャで使用されているオペレーティングシステムやテクノロジーによって、サービスアカウントの種類が異なる場合があることに注意することが重要です。

サービスアカウントはどのように作成されますか？

a) 管理者による独立した作成：管理者は、組織内の特定のサービスやアプリケーションを管理するためにサービスアカウントを作成できます。たとえば、組織が新しい内部アプリケーションやシステムを導入する場合、管理者はアプリケーションへの安全かつ制御されたアクセスを確保するために専用のサービスアカウントを作成できます。

b) オンプレミス型エンタープライズアプリケーションのインストール：オンプレミス型エンタープライズアプリケーション（例：顧客関係管理（CRM）ソフトウェア、企業資源計画（ERP）ソフトウェア）をインストールする際、インストールプロセスによって、アプリケーションのサービス、データベース、および統合を管理するための専用サービスアカウントが作成される場合があります。これらのアカウントは、アプリケーションのコンポーネントへのシームレスな運用と安全なアクセスを確保するために自動的に作成されます。

サービスアカウントは特権アカウントですか？

はい、サービスアカウントは特権アカウント. 特権アカウントサービスアカウントを含むサービスアカウントは、ITシステム内で高い権限とアクセス許可を持っています。サービスアカウントは、機密データへのアクセスや管理機能の実行など、特定のタスクを実行するために高い権限を必要とすることがよくあります。しかし、サービスアカウントに割り当てられた権限を慎重に管理および制限し、最小特権また、セキュリティ侵害や不正アクセスによる潜在的な影響を最小限に抑える。

ローカルアカウントはサービスアカウントですか？

いいえ、ローカルアカウントは必ずしもサービスアカウントではありません。ローカルアカウントは単一のデバイスまたはシステムに固有のものであり、通常はそのデバイスと直接やり取りするユーザーに関連付けられています。一方、サービスアカウントはシステム間またはアプリケーション間の通信用に設計されており、個々のユーザーではなく、アプリケーションまたはサービスのIDと認証を表します。

サービスアカウントはドメインアカウントですか？

サービスアカウントはドメインアカウントにすることもできますが、すべてのサービスアカウントがドメインアカウントであるとは限りません。ドメインアカウントはWindowsドメインに関連付けられており、そのドメイン内の複数のシステムで使用できます。サービスアカウントは、単一のシステム専用のローカルアカウントとして作成することもできます。サービスアカウントにドメインアカウントを使用するかローカルアカウントを使用するかは、IT環境の具体的な要件とアーキテクチャによって異なります。

サービスアカウントは共有アカウントですか？

ある意味では、サービスアカウントは共有アカウントと考えることができます。しかし、サービスアカウントは、複数の人間ユーザーが使用する従来の共有アカウントとは異なります。サービスアカウントはアプリケーションやサービス間で共有され、アプリケーションやサービスが認証を行い、ユーザーに代わってアクションを実行できるようにします。人間ユーザーが使用する共有アカウントとは異なり、サービスアカウントは個々のユーザーとは別の固有の識別子と認証情報を持ち、システム間の通信と自動化を促進する目的で管理されます。

サービスアカウントはセキュリティリスクとなるのか？

サービスアカウント Active Directory 環境は、特に次のような点で重大なサイバーセキュリティリスクをもたらす可能性があります。横移動攻撃。横方向移動とは、攻撃者が初期アクセス権を取得した後、ネットワーク内を移動して貴重なリソースにアクセスし、権限を昇格させることを目的とする手法を指します。

重要な弱点の1つは、サービスアカウントの可視性が低いことです。サービスアカウントは、組織のネットワーク内でさまざまなアプリケーション、サービス、または自動化されたプロセスを実行するために作成されることがよくあります。これらのアカウントには通常、データベース、ネットワーク共有、または重要なシステムへのアクセスなど、指定されたタスクを実行するための高いアクセス権限が付与されます。しかし、自動化された性質と分散管理のため、サービスアカウントはしばしば見落とされ、適切な監視が行われていません。このような可視性の欠如により、セキュリティチームはサービスアカウントに関連する悪意のある活動を監視および検出することが困難になります。

サービスアカウントに付与される高いアクセス権限は、別のリスクをもたらします。サービスアカウントには広範な権限が付与されているため、これらのアカウントが侵害されると、攻撃者は機密データや重要なシステムに広範囲にアクセスできるようになります。攻撃者がサービスアカウントを制御下に置くと、ネットワーク内を横断的に移動し、疑われることなくさまざまなシステムやリソースにアクセスできる可能性があります。サービスアカウントの高い権限は、アクセス権限を昇格させ、悪意のある目的を達成しようとする攻撃者にとって魅力的な標的となります。

さらに、サービスアカウントのパスワードをローテーションする特権アクセス管理において（PAM）vault はリスクをさらに高めます。定期的にパスワードを変更することは、影響を軽減するのに役立つ基本的なセキュリティ対策です。侵害されたクレデンシャルしかし、サービスアカウントは自動化されており、さまざまなシステムに依存しているため、従来のパスワードローテーションメカニズムと容易に統合できないことがよくあります。この制約により、サービスアカウントのパスワードが長期間変更されないままになり、侵害のリスクが高まります。攻撃者はこの脆弱性を悪用し、変更されないパスワードを利用して永続的なアクセス権を取得し、横方向の移動攻撃を実行する可能性があります。

サービスアカウントは、AIを活用した攻撃者による新たな、そして加速するリスクに直面しています。2026年、Anthropic社のMythos AIシステムは、エンタープライズ環境全体における主要な攻撃経路としてサービスアカウントを特定し、悪用しました。これは、新しい技術を使用せず、既に存在する過剰な権限を持つ監視されていないアカウントのみを利用したものです。ある事例では、単一の過剰な権限を持つサービスアカウントに対する仮想フェンシングが、ドメイン全体の侵害を阻止しました。AIエージェントが攻撃手段としてますます利用されるようになるにつれ、ほとんどのサービスアカウントの静的で監視されていない性質が、最も抵抗の少ない攻撃経路となっています。組織がこの脅威クラスに対してどのように対策を講じているかについては、以下をご覧ください。 SilverfortのフロンティアAI準備フレームワーク.

サービスアカウントのセキュリティ対策が不十分な使用例として、どのようなものがありますか？

認証情報の共有：管理者は、複数のサービスアカウントまたは異なる環境間で同じ認証情報（ユーザー名とパスワード）を使用する場合があります。このような行為は、認証情報が漏洩した場合の影響を増大させる可能性があります。なぜなら、攻撃者が1つのサービスアカウントへのアクセス権を取得すると、他のアカウントやシステムにもアクセスできる可能性があるからです。
脆弱なパスワード：管理者は、サービスアカウントに脆弱なパスワードや推測されやすいパスワードを使用する場合があります。脆弱なパスワードは、総当たり攻撃やパスワード推測の手法によって容易に悪用され、不正アクセスにつながる可能性があります。
パスワードのローテーション不足：サービスアカウントのパスワードが定期的に変更されていません。サービスアカウントのパスワードが長期間変更されない場合、攻撃者が同じ認証情報を繰り返し使用する機会を与え、不正アクセスのリスクが高まります。
過剰な権限: 管理者はサービスアカウントに過剰な権限を割り当て、意図したタスクを実行するために必要な以上の権限を付与する可能性があります。これにより、より広範な影響が生じる可能性があります。攻撃対象サービスアカウントが侵害された場合、攻撃者が機密データやシステムにアクセスできるようになります。
監視と監査の不足：管理者がサービスアカウントの活動を積極的に監視または確認していない可能性があります。適切な監視と監査が行われないと、侵害されたサービスアカウントに関連する悪意のある活動が見過ごされ、攻撃者が検知されずに活動を続ける可能性があります。
アクセス制御の不備：管理者は、サービスアカウントに対してきめ細かなアクセス制御を適切に実装していない場合があります。例えば、必要なアクセス権限が限定的なサービスアカウントに対して、機密性の高いシステムやリソースへの無制限のアクセスを許可してしまう可能性があります。このような場合、サービスアカウントが侵害された際に、不正アクセスやデータ漏洩のリスクが高まります。

攻撃者はどのようにしてKerberoastingを利用してサービスアカウントを発見し、侵害するのでしょうか？

認証情報の共有：管理者は、複数のサービスアカウントまたは異なる環境間で同じ認証情報（ユーザー名とパスワード）を使用する場合があります。このような行為は、認証情報が漏洩した場合の影響を増大させる可能性があります。なぜなら、攻撃者が1つのサービスアカウントへのアクセス権を取得すると、他のアカウントやシステムにもアクセスできる可能性があるからです。
脆弱なパスワード：管理者は、サービスアカウントに脆弱なパスワードや推測されやすいパスワードを使用する場合があります。脆弱なパスワードは、総当たり攻撃やパスワード推測の手法によって容易に悪用され、不正アクセスにつながる可能性があります。
パスワードのローテーション不足：サービスアカウントのパスワードが定期的に変更されていません。サービスアカウントのパスワードが長期間変更されない場合、攻撃者が同じ認証情報を繰り返し使用する機会を与え、不正アクセスのリスクが高まります。
過剰な権限：管理者はサービスアカウントに過剰な権限を割り当て、本来のタスクを実行するために必要な権限以上の権限を付与してしまう可能性があります。その結果、サービスアカウントが侵害された場合、攻撃対象領域が拡大し、攻撃者が機密データやシステムにアクセスできるようになる恐れがあります。
監視と監査の不足：管理者がサービスアカウントの活動を積極的に監視または確認していない可能性があります。適切な監視と監査が行われないと、侵害されたサービスアカウントに関連する悪意のある活動が見過ごされ、攻撃者が検知されずに活動を続ける可能性があります。
アクセス制御の不備：管理者は、サービスアカウントに対してきめ細かなアクセス制御を適切に実装していない場合があります。例えば、必要なアクセス権限が限定的なサービスアカウントに対して、機密性の高いシステムやリソースへの無制限のアクセスを許可してしまう可能性があります。このような場合、サービスアカウントが侵害された際に、不正アクセスやデータ漏洩のリスクが高まります。

なぜできないのか Active Directory サービスアカウントの在庫状況を可視化する？

標準化された命名規則の欠如: サービスアカウントは、組織内のさまざまなチームや部門によって作成および管理されることがよくあります。標準化された命名規則や一貫したドキュメント作成方法がない場合、サービスアカウントを識別し、区別する通常ユーザーアカウントから Active Directory.
分散型管理：サービスアカウントは、さまざまなアプリケーション所有者やシステム管理者によって作成および管理される場合があり、結果として分散型のアプローチとなります。この分散化により、組織全体のサービスアカウントの完全なインベントリに対する集中的な監視と可視性が失われる可能性があります。
不十分なドキュメント: サービスアカウントには、その目的、関連システム、特権アクセスレベルに関する情報など、適切なドキュメントが不足している場合があります。このような包括的なドキュメントの欠如により、正確なインベントリを維持し、サービスアカウントの範囲を理解することが困難になります。 Active Directory.
サービスアカウントの動的な性質：サービスアカウントは、自動化されたプロセスやアプリケーションを実行するためによく使用され、組織のニーズに応じて作成や削除が頻繁に行われることがあります。このような動的な性質のため、特に大規模で複雑な組織では、すべてのサービスアカウントをリアルタイムで追跡することが困難になる場合があります。 Active Directory 環境。

攻撃者は、サービスアカウントへの初期アクセスを取得した後、どのようにしてサービスアカウントを発見できるのでしょうか？ Active Directory 環境？

Active Directory 列挙: 攻撃者は、BloodHound、PowerView、LDAPクエリなどのツールを利用して列挙することができます。 Active Directory オブジェクトを照会し、サービスアカウントを識別します。 Active Directory servicePrincipalNameやuserAccountControlなどの属性を利用することで、攻撃者はサービスアカウントとして特別に指定されたアカウントを特定できる。
ネットワークトラフィック分析: 攻撃者はネットワークトラフィックを監視できます Active Directory サービスアカウントを示すパターンや動作を特定するための環境を分析する。例えば、サービスやシステムなどの非対話型ソースからの認証要求を探すことで、潜在的なサービスアカウントを特定できる場合がある。
セキュリティイベントログ：攻撃者は、侵害されたシステムやドメインコントローラーのセキュリティイベントログを調べて、サービスアカウントに関連付けられたログオンイベントを特定する可能性があります。ログオンの種類とアカウント名を調べることで、サービスアカウントの存在と使用状況に関する情報を得ることができます。
サービスディスカバリ：攻撃者は、侵害したシステム上でサービスディスカバリ技術を実行し、実行中のサービスやプロセスを特定する可能性があります。サービスアカウントのコンテキストで実行されているサービスを探すことで、それらのアカウントの存在や場所に関する貴重な情報を得ることができます。
設定ファイルとドキュメント：攻撃者は、侵害したシステム上で、サービスアカウントへの参照を含む設定ファイル、ドキュメント、またはその他のアーティファクトを検索する可能性があります。これらのファイルには、サービスアカウントを明示的に言及または参照するアプリケーション設定、スクリプト、またはバッチファイルが含まれる可能性があります。

サービスアカウントの脆弱性と対策

サービスアカウントは、大きなメリットがある一方で、ITシステム内で特定のセキュリティリスクをもたらす可能性があります。しかし、効果的な緩和策を実施することで、組織はサービスアカウントのセキュリティ体制を強化する。考慮すべき重要な点は次のとおりです。

一般的なセキュリティリスク

認証情報の漏洩と暴露サービスアカウントは、パスワード管理の不備や、コードまたは設定ファイル内で認証情報が意図せず漏洩するなど、認証情報漏洩のリスクにさらされる可能性があります。これらの認証情報への不正アクセスは、システム侵害につながる恐れがあります。

特権エスカレーションサービスアカウントに過剰な権限が付与されている場合、またはサービスアカウントが連携するアプリケーションやシステムに脆弱性がある場合、権限昇格のリスクがあります。攻撃者はこれらの脆弱性を悪用して、機密データへの不正アクセスや不正な操作を実行する可能性があります。

緩和戦略

定期的な脆弱性評価定期的な脆弱性評価と侵入テストを実施することで、サービスアカウントにおける潜在的な脆弱性を特定し、対処することができます。これらの評価により、脆弱な認証メカニズム、安全でない設定、またはサービスアカウントの認証情報が漏洩する可能性のあるコーディング上の脆弱性が明らかになる場合があります。

適切なアクセス制御と隔離適切なアクセス制御と職務分掌を実施することで、サービスアカウントには必要最低限の権限のみが付与され、本来の目的に必要なリソースへのアクセスのみが許可されます。この最小権限の原則により、潜在的な侵害や不正アクセスによる影響を軽減できます。

セキュリティポリシーとガイドラインの実施

強力なセキュリティ文化の徹底組織は、サービスアカウントに関して安全な運用方法の重要性を強調する、強固なセキュリティ文化を確立し、徹底する必要があります。これには、パスワード管理のベストプラクティスの推進、サービスアカウントに関連するリスクについての意識向上、そしてセキュリティに対する積極的なアプローチの促進が含まれます。

セキュリティのベストプラクティスを文書化して共有するサービスアカウントに特化した包括的なセキュリティポリシーとガイドラインを策定し共有することで、組織全体で一貫性のある安全なアプローチを確立できます。ドキュメントには、安全なパスワード管理、サービスアカウント活動の定期的な監査、サードパーティシステムやクラウドサービスとの安全な統合に関するガイドラインなどを網羅する必要があります。

サービスアカウントを保護するためのベストプラクティス

強固なセキュリティ対策を実施することは、サービスアカウントを潜在的な脅威から保護するために不可欠です。以下に重要な点を示します。サービスアカウントを保護するためのベストプラクティス:

強力な認証メカニズム

多要素認証（MFA）: 使用を強制するマルチファクタ認証サービスアカウント向け。 MFA パスワードに加えて、ワンタイムパスワード、生体認証、ハードウェアトークンなどの追加の認証を要求することで、セキュリティをさらに強化します。
キーベース認証サービスアカウントに対して、公開鍵認証とも呼ばれる鍵ベース認証を実装します。この方式では暗号鍵ペアを使用し、秘密鍵は安全に保管され、公開鍵は認証に使用されます。鍵ベース認証は、従来のパスワードベース認証に比べてセキュリティが強化されます。

定期的なパスワードの変更と複雑性

パスワードポリシーに関する推奨事項サービスアカウント向けに、パスワードの長さ、複雑さ、有効期限などの要件を含む包括的なパスワードポリシーを策定してください。パスワードが推測されにくいものであること、また複数のアカウントで同じパスワードを使い回さないことを確認してください。
パスワードの自動ローテーションサービスアカウントのパスワードを定期的に変更するプロセスを自動化します。強力で固有のパスワードを自動的に生成し、事前に定義されたスケジュールで更新するシステムを導入します。パスワードの自動変更により、古いパスワードや脆弱なパスワードによる認証情報の漏洩リスクを軽減できます。

認証情報の安全な保管：

暗号化ストレージオプションサービスアカウントの認証情報は、保存時および転送時ともに暗号化された形式で保存してください。業界標準の暗号化アルゴリズムを使用し、暗号化された認証情報へのアクセスは、許可された個人またはシステムのみに限定してください。
認証情報をハードコーディングすることを避けるサービスアカウントの認証情報をアプリケーションコードや設定ファイルに直接ハードコーディングすることは避けてください。代わりに、パスワード保管庫やセキュアな鍵管理システムなどの安全な認証情報保存ソリューションを活用して、必要なときに認証情報を安全に保存および取得してください。

安全な通信と暗号化：

トランスポート層セキュリティ（TLS）サービス間の通信は、トランスポート層セキュリティ（TLS）プロトコルを使用した安全なチャネルで行われるようにしてください。TLSは送信中にデータを暗号化し、サービス間で交換される機密情報の盗聴や改ざんを防ぎます。
サービス間通信のためのセキュアなプロトコルサービス間通信には、HTTPSやSSHなどの安全なプロトコルを選択してください。これらのプロトコルは強力な暗号化と認証メカニズムを採用しており、サービス間で交換されるデータを不正アクセスや改ざんから保護します。

サービスアカウントの説明