API セキュリティの重要性を理解したところで…
(現在の業界トピックとしての API セキュリティの台頭について簡単に知るには、この最近のブログ投稿をご覧ください。 以下のガイダンスはそこから始まり、それに対して何ができるかを概説するのに役立ちます。
APIゲートウェイをセキュリティゲートウェイで補完する
API の爆発的な成長により、API ゲートウェイと API セキュリティの両方において新たな市場が生まれています。 これらは将来的に統合される可能性がありますが、現在では、脅威を軽減するために、API ゲートウェイの前に有能な Webapplicationファイアウォール (WAF) を配置することができます。 WAF は、IP インテリジェンス、攻撃シグネチャ、悪意のあるボットの検出、OWASP Top 10 ルール セットなどのすぐに使用できる機能を使用して、既知の不正なトラフィックが API ゲートウェイに到達する前にブロックできます。 F5 Advanced WAFなどのより成熟した WAF には専用の機能があり、グローバルなドメインごとのルール セットだけでなく、単一のドメイン内の複数の API を保護するようにセキュリティ ポリシーをカスタマイズできます。
現在および新たなニーズに対処するには、次の 3 つの点に留意してください。
- API ゲートウェイは戦略的な制御ポイントになりました。 テクノロジーの移行により人間以外のトラフィックがさらに増加するにつれて、API がビジネスの中心になります。 API ゲートウェイはエッジに配置され、すべての API トラフィックの入力ポイントとなります。 API セキュリティを効果的にするには、より豊富なコンテキスト、分析、発信者 ID、相関機能が必要です。
- API ゲートウェイと API セキュリティ サービスの間には大きなギャップがあります。 従来のアプリ セキュリティ ベンダーには、バージョン管理、オーケストレーション、メータリングなどの最低限の API ゲートウェイ機能が欠けています。 ほとんどの API ゲートウェイ ソリューションには、ほとんどの WAF ソリューションで利用できる標準的なセキュリティ制御が欠けています。 適切な機能とセキュリティを確保するには、両方が必要になります。
- このギャップはセキュリティ ゲートウェイで解決できます。 API 保護機能を備えAdvanced WAFを追加すると、ほとんどの API ゲートウェイのセキュリティ上の欠陥を克服できます。 F5 Advanced WAF は、セキュリティ機能を API とマイクロサービスにまで拡張しました。 これは API ゲートウェイの拡張機能を置き換えることはできませんが、一般的なセキュリティ制御を改善し、強化することができます。 F5 Advanced WAF は宣言型 API もサポートしているため、アジャイル環境向けに API セキュリティ ポリシーを調整および自動化できます。
セキュリティゲートウェイはセキュリティの欠陥を補うことができますが、怠惰になってはいけません
テクノロジーが成熟するにつれて、API ゲートウェイは追加の API セキュリティ上の懸念に対処するのに役立ちますが、まだそこまでには至っていません。 計画とベスト プラクティスは、短期的に API を適切に保護するのに大いに役立ちます。 API を効果的に保護するには、次の点に注意してください。
- 常にセキュリティゲートウェイを使用してください。 クライアントが認証されていない状態で API に直接アクセスできないようにします。既知の不正なトラフィックをドロップできるセキュリティ ゲートウェイまたはプロキシを経由するようにすべてのトラフィックを強制します。 既存の WAF がある場合はそれを活用します。 より包括的なソリューションを検討している間、基本的な WAF でも緊急時には機能します。
- シンプルにしましょう。 持っている DevOps と SecOps は、API を開発するための一連の標準 (OpenAPI/Swagger など) に同意します。 標準は、API のドキュメント化とテストに役立ちます。 OpenAPI 3.0 には、安全な設計の実装を支援するために再利用できる専用のセキュリティ コンポーネントがあります。 OpenAPI 標準を使用すると、Crunch42 などの監査および適合ツールを使用して、設計とセキュリティ テストを自動化することもできます。
- セキュリティ要件を定義します。 API 要件の範囲には通常、API に必要な機能のみが含まれます。つまり、API が実行する必要がある機能を定義します。 API 要件には、セキュリティ要件 (API が実行できないこと) も含める必要があります。 セキュリティが設計仕様の一部となることで、セキュリティは API の機能テストの一部になります。
- API サービス(API クライアントとサーバー) の脅威モデルを作成します。 提案されたシステムの脅威モデリングを実行すると、主要な資産/コンポーネントと脅威のカテゴリを特定するのに役立ちます。 特定された脅威を軽減するために、セキュリティ設計要件を追加できます。 コントロールが API とアプリの望ましいリスク モデルと一致していることを確認します。
- 認証と承認をオフロードします。 最新の認証と承認には API ゲートウェイを活用します。 すべての API は、デプロイメントの一部として認証を行う必要があります。 これをアプリ自体に組み込む必要はありません (認証されていないトラフィックを API に直接転送すると攻撃に対して脆弱になる可能性があるため、これはベスト プラクティスではありません)。 利用できる認証形式はいくつかあり、リスクベースのアプローチが選択に役立ちます。 Oauth 2.0 は一般に、REST API に最適なオプションと考えられています。 F5 BIG-IP APM は、これらの制御を実装するための優れたソリューションです。
- すべてを暗号化します。 暗号化を使用しない言い訳はありません。 SSL/TLS は、すべてのインターネット トラフィックで 100% に近づいています。 すべてのパブリック API トラフィックは暗号化する必要があります。 可能であれば、セキュリティを強化するために一時キーを使用してください (Heartbleed を覚えていますか?)。 パフォーマンスや価格の理由で API ゲートウェイが暗号化ワークロードを処理できない場合は、 F5 SSL Orchestratorなどの専用システムにワークロードをオフロードすることを検討してください。
- セキュリティに関する開発者の「創造性」を阻害します。 セキュリティを適切に行うのは困難です。セキュリティ コミュニティは数十年にわたってこれに取り組んでいますが、依然として欠陥が見つかり続けています。 開発者が優秀であっても、新しい暗号化モデルなどのカスタマイズされたセキュリティ制御を発明することには十分注意してください。 この種のセキュリティの「独創性」を回避するには、標準化され、十分に検証されたベースライン セキュリティ制御を DevOps に必ず提供してください。 特別にカスタマイズされたセキュリティ制御が必要な場合は、SecOps チームに相談する必要があります。
API の使用は、新しいビジネス モデルと収益源を実現することで変革をもたらす可能性があります。 ただし、適切なガードレールなしに実装された API は、ビジネスを混乱させ、リスクにさらす可能性もあります。 API セキュリティはまだ比較的新しい技術分野と考えられていますが、上記のプラクティスは、周囲のソリューションが成熟するにつれて、現在の API セキュリティのギャップに対処するのに役立ちます。