APIセキュリティの重要性を理解したら……

F5

（APIセキュリティが現在の業界トピックとして注目を集めるようになった経緯を手早く把握するには、こちらの「最近のブログ記事」をご覧ください。以下では、その内容を踏まえ、どのような対策を講じられるかを概説します。）

セキュリティゲートウェイでAPIゲートウェイを補完

APIの爆発的な増加により、APIゲートウェイとAPIセキュリティの両方で新たな市場が生まれています。将来的には両者が統合される可能性もありますが、現時点では、高機能なWebアプリケーションファイアウォール（WAF）をAPIゲートウェイの前段に配置することで、脅威を軽減できます。WAFは、IPインテリジェンス、攻撃シグネチャ、悪意のあるボットの検知、OWASP Top 10ルールセットなどの標準機能を使用して、既知の悪意あるトラフィックがAPIゲートウェイに到達する前にブロックできます。より高度なWAF（F5 Advanced WAFなど）は専用機能を備えており、ドメイン単位のグローバルなルールセットだけでなく、単一ドメイン内の複数のAPIを保護できるようにセキュリティポリシーをカスタマイズできます。

現在および今後生じるニーズに対応するうえで、次の3点に留意してください。

1. APIゲートウェイは戦略的な制御ポイントになっています。テクノロジーの移行に伴って人間以外によるトラフィックがさらに増加する中、APIはビジネスの中核となります。APIゲートウェイはエッジに配置され、すべてのAPIトラフィックの入口となります。APIセキュリティを効果的に機能させるには、より豊富なコンテキスト、分析、呼び出し元ID、相関分析の機能が必要です。
   
   
2. APIゲートウェイとAPIセキュリティ製品の間には大きな隔たりがあります。従来のアプリケーションセキュリティベンダーの製品には、バージョン管理、オーケストレーション、使用量計測など、APIゲートウェイに最低限必要な機能がありません。一方、ほとんどのAPIゲートウェイソリューションには、多くのWAFソリューションが備える標準的なセキュリティ制御がありません。十分な機能とセキュリティを確保するには、両方が必要です。
   
   
3. このギャップは、セキュリティゲートウェイで対処できます。 API保護機能を備えたAdvanced WAFを追加することで、ほとんどのAPIゲートウェイにおけるセキュリティ上の不備の解消に役立ちます。F5 Advanced WAFは、APIとマイクロサービスにも対応できるようセキュリティ機能を拡張しています。APIゲートウェイの高度な機能を代替することはできませんが、一般的なセキュリティ制御を強化し、適用できます。また、F5 Advanced WAFは宣言型APIにも対応しているため、アジャイル環境向けのAPIセキュリティポリシーをオーケストレーションし、自動化できます。
   

セキュリティゲートウェイでセキュリティ上の不備を補完できても、油断は禁物

テクノロジーが成熟すれば、APIゲートウェイは、より広範なAPIセキュリティ上の懸念への対処に役立つようになりますが、現時点ではまだ十分ではありません。当面の間、APIを適切に保護するには、計画の策定とベストプラクティスの実践が大いに役立ちます。APIを効果的に保護するため、以下を忘れずに実施してください。

1. 必ずセキュリティゲートウェイを使用する。 クライアントに認証なしでAPIへの直接アクセスを許可しないでください。すべてのトラフィックを、既知の悪意あるトラフィックを遮断できるセキュリティゲートウェイまたはプロキシ経由にします。既存のWAFがある場合は活用してください。より包括的なソリューションを検討する間の応急措置として、基本的なWAFでも利用できます。
   
   
2. シンプルに保ちましょう。DevOpsとSecOpsの間で、API開発に使用する一連の標準（OpenAPI/Swaggerなど）について合意しておきます。標準を使用することで、APIの文書化とテストが容易になります。OpenAPI 3.0には、セキュアな設計の実装に役立つ、再利用可能な専用セキュリティコンポーネントがあります。また、OpenAPI標準を使用すると、Crunch42などの監査・適合性確認ツールを活用して、設計とセキュリティのテストを自動化できます。
   
   
3. セキュリティ要件を定義する。通常、API要件の範囲には、APIに求められる機能、つまりAPIが実行すべき機能の定義のみが含まれます。API要件には、セキュリティ要件（APIが実行できてはならないこと）も含める必要があります。設計仕様にセキュリティを組み込むことで、APIの機能テストにもセキュリティが含まれるようになります。
   
   
4. APIサービスの脅威モデルを作成する – APIクライアントとサーバー。 提案するシステムの脅威モデリングを実施することで、主要な資産／コンポーネントと脅威のカテゴリーを特定しやすくなります。その後、特定した脅威を軽減するためのセキュリティ設計要件を追加できます。コントロールがAPIとアプリに求められるリスクモデルに沿っていることを確認してください。
   
   
5. 認証と認可をオフロードする。最新の認証と認可にはAPIゲートウェイを活用します。すべてのAPIで、デプロイの一環として認証を実装する必要があります。アプリ自体に認証を組み込む必要はありません（未認証のトラフィックをAPIに直接転送すると、APIが攻撃を受けやすくなる可能性があるため、ベストプラクティスでもありません）。利用できる認証方式は複数あり、リスクベースのアプローチが選定に役立ちます。一般に、REST APIにはOAuth 2.0が最適な選択肢とされています。F5 BIG-IP APMは、これらの制御を実装するための優れたソリューションです。
   
   
6. すべてを暗号化する。暗号化しない理由はありません。インターネットトラフィック全体におけるSSL/TLSの使用率は100%に近づいています。すべてのパブリックAPIトラフィックを暗号化する必要があります。可能であれば、セキュリティをさらに強化するためにエフェメラルキーを使用してください（Heartbleedを覚えていますか？）。APIゲートウェイがパフォーマンスやコストの問題で暗号化処理の負荷に対応できない場合は、ワークロードをF5 SSL Orchestratorなどの専用システムにオフロードすることを検討してください。
   
   
7. セキュリティに関する開発者の「独創性」を抑える。セキュリティを適切に実装するのは容易ではありません。セキュリティコミュニティは数十年にわたって取り組んできましたが、それでも脆弱性は見つかり続けています。開発者がどれほど優秀でも、新しい暗号化モデルなど、独自のセキュリティ制御を考案することには細心の注意が必要です。このようなセキュリティ上の「独創性」を避けるため、標準化され、十分に検証されたベースラインのセキュリティ制御をDevOpsに必ず提供してください。個別に調整したセキュリティ制御が必要な場合は、SecOpsチームに相談してください。

APIの活用は、新たなビジネスモデルや収益源を実現し、ビジネスに変革をもたらす可能性があります。しかし、十分なガードレールを設けずにAPIを実装すると、ビジネスに混乱を招き、リスクにさらすおそれもあります。APIセキュリティは、まだ比較的新しい技術分野と見なされることもありますが、関連ソリューションが成熟するまでの間、上記のプラクティスは、現時点でのAPIセキュリティのギャップへの対処に役立ちます。

著者について

F5

F5のその他のブログ記事