TLS 相互認証がクラウド API を保護する方法を理解する

サイバーセキュリティの世界で長い間守られてきた慣行があります。「絶え間ない変化または進化は、アプリケーションを永遠に安全に保つ唯一の方法です」.

これまで、コンポーネント間認証は多くのアプリケーションにとって面倒でした。アプリは、アクセスを取得するために、クラウド API のさまざまなミドルウェアおよびバックエンド コンポーネントに対して自身を検証する必要がありました。ただし、Web API でのアプリケーション認証は不可欠なプロセスです。

検証のための既存のメカニズムは、静的アプリケーション ログインです。しかし、この方法にはセキュリティ上の問題があります:–

• ログイン資格情報は時々更新されます。
• アプリケーションのアクティビティを確認および記録する会社の能力が低下します。

関連記事:DevSecOps:予定アプリケーションとソフトウェアの保護にご協力いただけますか?

TLS 相互認証

ただし、クラウド API セキュリティを支援する最善の方法の 1 つは、コンポーネントまたはプロセスが相互に通信するときに TLS (Transport Layer Security) 相互認証を導入することです。

RESTful API コンポーネントがすでに TLS 相互認証技術を使用していると仮定しましょう。これは、アプリケーションが自身を検証するためにクライアント証明書を提示するように要求します。したがって、アプリケーション セキュリティ インフラストラクチャ戦略の改善に役立ちます。

従来のプロセスの問題

通常のプロセスのアクティビティは、バックエンド コンポーネントに従って 1 つのユーザー ID の下にまとめられます。この分類により、アプリケーションに関連するイベント情報全体からイベントを見つけるのが難しくなります。サイバー攻撃中にイベントが見つからない場合、状況はさらに悪化します。セキュリティの専門家は、無害なアプリケーションと有害なアプリケーションを区別できません。この特定の問題は 10 年前から蔓延しており、まだ解決されていません。

RESTful API の場合、相互に検証する必要があり、HTTP 対応の方法を使用して認証を実行するだけです。たとえば、非表示の値が HTTP リクエスト ヘッダーに統合されて、リクエスタが検証されます。このプロセスは、HTTP 基本認証と呼ばれます。クラウド アプリケーションがクラウド内にあるかオンプレミスにあるかを無視して適用されます。 PaaS と IaaS のどちらを使用する場合でも、コンポーネント間認証は未解決の問題です。

TLS がどのように役立つか

基本的に、TLS の機能を利用して、実装する認証メカニズムを強化する必要があります。万が一、TLS が Web サーフィンに利用されていない場合、相互に取引しているピア間の相互検証をサポートします。

サーバーは、ブラウザーがリモート Web サイトを認証するのと同じように、リクエスターを認証します。 HTTP プロトコルはクラウド API のトランスポートとして使用されますが、コンポーネント間の相互検証を引き続き許可できます。 TLS 相互認証では、受け入れ可能な証明書のパラメーターを特に制限できます。これは、クラウド アプリケーションが特定の証明書またはシリアル番号を提示するだけでよく、さらに特定の認証局からのものであることを意味します。さらに、TLS メソッドを静的な隠し値またはパスワードと組み合わせることができます。ただし、クラウドでの TLS 相互認証アプローチの実装にはいくつかの依存関係があります。主に、クラウド API は、TLS 相互認証を設定するためにカスタマイズ可能である必要があります。つまり、構成を変更できるように IaaS 環境が必要です。それ以外の場合は、この機能をオンにできる PaaS 環境である必要があります。 AWS や Microsoft Azure などのクラウド エキスパートの例を挙げることができます。

TLS 相互認証の利点

TLS 相互認証を使用すると、いくつかの驚くべき利点が得られます。 TLS 相互認証の最も顕著な利点の 1 つは、パスワードや秘密の値を維持する手間が省けることです。パスワードまたは静的な隠し値の使用と管理は、パスワードの定期的な変更、使用状況の確認、複雑なパスワードの作成、保護の確保などのプロセスが含まれるため、面倒な作業です。ただし、TLS 相互認証により、パスワードを維持するための余分な手間が軽減されます。認証方法を有効にする際にパスワードが使用されることはほとんどありませんが、長期的には TLS によってパスワードの役割が減少する可能性があります。

それに加えて、TLS 相互認証は、パスワードより移植性が低い証明書と秘密鍵を使用します。したがって、証明書と秘密鍵は他のデジタル エンティティと同様に危険にさらされる可能性がありますが、ハッカーがリモート API 呼び出し元になりすますことを望んでいる間に、少なくともロジスティクスの観点から、ハッカーにとっての難易度は依然として高くなります。

アプリケーションの監視に関する限り、TLS は API リクエストをより明確に行うコンポーネントまたはアプリケーションの記録を保持します。パスワードを使用すると、複雑なプロセスになります。

関連記事: サイバー セキュリティは改善されていますか、それとも悪化していますか?

TLS 相互認証のデメリット

TLS 相互認証を実装する際のデメリットはほとんどありません。ただし、それらのどれも、この手法の実装を思いとどまらせるべきではありません。

メソッドを強化するには、次のデメリットを考慮する必要があります。 –

何よりもまず、証明書の有効期限が切れます。したがって、有効期限が切れる前に証明書を再発行することを常に忘れないでください。証明書を再発行するのを忘れた場合、問題をデバッグするのが難しいため、悲惨な結果になる可能性があります。期限切れの証明書を積極的に置き換えるために、証明書の有効期限を常に追跡してください。

全体として、TLS 相互認証は、クラウド API のセキュリティを向上させる建設的な方法です。少なくとも、TLS 相互認証は、セキュリティの専門家がクラウド上のアプリケーション セキュリティを評価するのに役立ちます。