マシンのユーザー管理の設計

InfoWorld | Aviad Mizrachi 著

技術者が解剖する新興テクノロジー

ユーザーに人間的な特徴がなく、個性があまりない場合、これには十分な理由がある可能性があります。ユーザーは機械である可能性があります。

現在、インターネットトラフィックの 90% 以上がマシン間で行われています。実際には、B2B SaaS アプリケーションを使用するマシンもユーザーであり、単なる異なる種類のユーザーです。そのため、今日のすべてのオンラインおよび SaaS アプリケーションには、マシンツーマシン (M2M) インタラクションのさまざまな課題や要件に対処するために特別に設計された、よく考えられたユーザー管理の実践とポリシーが組み込まれている必要があります。

B2B SaaS 企業による M2M インタラクションの処理を支援してきた長年の経験に基づいて、効率的、効果的、安全なマシン間のユーザー管理のためのベストプラクティスをまとめたクイックガイドをまとめました。飛び込んでみましょう。

コンテキストは人間のユーザー管理では重要かもしれませんが、マシンユーザーが自分のステータス、状況、意図について提供する情報がはるかに少ないため、マシンにとってはさらに重要です。多くの場合、マシンユーザーは 1 つまたは少数のサービスにのみアクセスしますが、人間のユーザーはさらに多くのサービスにアクセスします。

マシン間の対話には、ブラウザーエージェント、MAC アドレス、NIC アドレス、地理位置情報データなどの有用な手がかりは含まれません。これらは、最低限の識別特性を備えた一般的に使用されるプロトコルの API 呼び出しである可能性が高くなります。マシンユーザーが行うサービスリクエストのコンテキストによって、ポリシーがどのように適用され、ユーザー管理が設計されるかが決まります。

M2M ユーザー管理では、すべてのサービスが他のサービスと通信する方法と、どのサービスと通信する必要があるかを認識している必要があります。すべてのサービスは、別のサービスと通信する方法と、アクセス許可を与える必要がある主要なサービスを認識する必要があります。これは、API ゲートウェイとサービスメッシュが提供できる機能の一部ですが、どちらも (M2M ユーザーであっても) ユーザー中心のアプローチを持っていません。

今日の人間のユーザーにとって、MFA はセキュリティ検証プロセスの重要な部分です。マシンユーザーにとって、MFA はオプションではありません。同時に、マシンは人間よりもはるかに速い速度で対話できるため、M2M トランザクションはミリ秒単位で動作する傾向があります。これにより、新たな攻撃対象領域が生まれ、現在、多くのサイバー犯罪者が API 攻撃を通じて積極的に悪用しようとしています。これは、M2M インタラクションに対するユーザー管理プロセスを実行している SecDevOps チームにとって、IP アドレス制限、リクエストレート制限、証明書またはキーのローテーションなどの他のセキュリティメカニズム、そして理想的には人間または機械が生成したポリシーに対して、より厳密な注意を払う必要があることを意味します。異常な使用パターンを認識します。

リクエストが内部マシンからのものであるか、外部ユーザーからのものであるかによって、セキュリティに関する考慮事項は大きく異なります。リクエストが内部的なもので、Kubernetes クラスター内からあるサービスから別のサービスに送信される場合、認証は内部的に適用され、通常はより軽い処理で適用されます。たとえば、サービスメッシュは、特定の内部サービスが接続できるサービスに関するポリシーを設定するために使用されます。実際には、多くの組織がまだ内部のマシン間の相互作用を認証できていませんが、CISO とリスク管理チームはあらゆる場所でベースライン認証の実装に力を入れています。

現在まで、多くのプラットフォーム運用チームと SecDevOps チームは、内部セキュリティに単純な認証、つまり共有シークレットを使用しています。ただし、単純な認証には、侵害された、または何らかの形で暴露されたシークレットを簡単に置き換えるための強力なプロセスが必要です。このシークレット交換プロセスがないと、組織は新しいシークレットの作成と共有中にダウンタイムが発生するリスクがあります。大規模な場合、マシンユーザーのペアまたはトリオ間で同期する必要があるシークレットへの変更は多大な作業になります。したがって、社内の M2M 通信であっても、技術的な課題は存在します。

外部 M2M 通信とマシンユーザー管理の場合、状況はさらに複雑になります。秘密分散ではセキュリティが不十分です。これを実証するために、次の例を考えてみましょう。ユーザーサービスと電子メールサービスという 2 つのサービスがあるとします。ユーザーに電子メールを送信したいと考えています。すべてのユーザーが電子メールを受信できるわけではありません。したがって、ユーザーを適切に管理するには、アプリケーションはどのユーザーに電子メールを送信する資格があるか、そのユーザーに送信されるメッセージにはどの電子メールを示す必要があるかを認識する必要があります。この世界では秘密はすぐに崩れてしまいます。

この使用例では、M2M JSON Web トークン (JWT) が汎用 M2M 通信サービスよりも好ましい理由も強調しています。ユーザー管理サービスは、特定のユーザーまたは特定の組織のトークンを生成する必要があります。トークンは取り消したり、一定の間隔で更新を要求するように設定したりできます。

適切に設計されたトークンライフサイクルポリシーと運用システムにより、セキュリティサービスとユーザー管理サービスは、運用を中断することなく、アクセスを迅速に取り消したり、キーをローテーションしたりすることができます。ポリシーは、証明書失効リストまたは更新リストを通じて自動的に適用されます。更新が比較的短いスケジュールで行われる場合は、M2M ユーザーにほぼゼロトラストを提供するようにユーザー管理を調整することが可能です。 JWT は複数の属性を保持できるため、コンテキストをエンコードする場合に特に役立ちます。

組織が外部認証を処理する 2 番目の方法は、アクセストークンを使用するもので、ユーザーは単一の値の文字列を受け取ります。アクセストークンの仕組みは次のとおりです。

アクセストークンは単純なトランザクションには非常に適していますが、より複雑なシナリオでは機能不全に陥り、単一障害点が発生する可能性があります。たとえば、何らかの理由でアクセストークンが検証されなかった場合、簡単な手段はなく、信頼を評価する他のメカニズムもありません。マイクロサービスアーキテクチャで実行すると、フローがより複雑になり、管理が難しくなります。マシンユーザーは、別の検証サーバーとサービストラックを使用して即時検証を行う必要があります。 JWT を使用する場合、サービスが知る必要があるのは、ユーザーがすべてのアクセスコンテキストを保存する有効な JWT を持っているかどうかだけです。これを検証するために別のプロセスを実行する必要はありません。

3 番目のパスはクライアントの資格情報です。これらは、クライアント ID やシークレットなど、アプリケーションによって提供される一連の識別情報であり、アプリケーションを認証し、リソースサーバーへのアクセスを許可するために使用されます。クライアント資格情報には JWT が組み込まれていることが多く、2 つの ID が必要なため、より安全であるという利点があります。また、クライアントの資格情報はユーザーフレンドリーではない場合がありますが、ユーザーが人間ではない場合はそれほど問題になりません。

ただし、クライアント資格情報を使用する場合は、障害を迅速に軽減し、ボトルネックを軽減できるようにシステムを慎重に設計する必要があります。 Google や OAuth などの他の分散システム、またはサードパーティのクラウド証明書やトークン認証局に依存している場合、これは特に困難になる可能性があります。このシナリオでは、組織は、生成または制御していない JWT に依存する可能性があります。

クライアント資格情報とアクセス制御の間の中間点は、相互 TLS (mTLS) である可能性があります。 mTLS は、ネットワーク接続の両端の当事者が両方とも正しい秘密キーを持っていることを確認することで、その当事者が本人であることを保証します。これにより、ハンドシェイクポイントで追加の信頼検証メカニズムが階層化されます。一部のサービスメッシュ、リバースプロキシ、および API ゲートウェイはデフォルトで mTLS を適用しますが、インフラストラクチャスタック全体で mTLS を同期するには、実際のシステム設計と慎重な検討が必要です。

サービスとマイクロサービスの数が増え続け、API 上に構築されるアプリケーションが増えるにつれ、M2M インタラクションのための強力なユーザー管理戦略と実践を開発することが重要になります。これはつまり：

マシンもユーザーであることを忘れないでください。彼らが使用するサービスが利用可能で、高速で、スケーラブルで、安全であることを保証するには、ユーザーをユーザーのように扱う必要があります。

Aviad Mizrachi は、Frontegg の CTO 兼共同創設者です。

—

New Tech Forum は、新たなエンタープライズテクノロジをこれまでにないほど深く幅広く調査し、議論する場を提供します。この選択は主観的なものであり、InfoWorld 読者にとって重要であり、最も関心があると思われるテクノロジの選択に基づいています。 InfoWorld は出版のためのマーケティング資料を受け入れず、投稿されたすべてのコンテンツを編集する権利を留保します。すべてのお問い合わせは [email protected] までお送りください。

次にこれを読んでください：

ブログ