執筆: API総研編集部
近年APIは、複数の企業が連携しながら大きなビジネス基盤を構築する上で必要不可欠な存在となっています。しかし、APIによってやり取りされるデータやビジネスロジックには、しばしば機密性や重要性が伴うため、適切なセキュリティレベルを設計し、正しく運用することが非常に重要です。
一方で、セキュリティ対策には必ず構築コストや運用負荷、APIの利用者（開発者体験）への影響が生じます。顧客にとって本当は必要のない過度なセキュリティレベルを最初から担保してしまうことで、その後の顧客の期待に継続的に応え続けることが難しくなったり、APIの提供価値やビジネスの成長スピード・スケーラビリティに大きな悪影響を及ぼすリスクがあります。
そのため、最初に業界ごとのビジネス要件や顧客ニーズについて、調査やヒアリングを行いながら正しく理解した上で、「必要十分」なセキュリティ要件を正しく定義し、APIを構築し始めることが重要です。
この記事では、APIセキュリティレベルをどの程度まで担保すべきか、その判断基準や手法、そしてAPIを利用する顧客との合意形成におけるポイントについて記載します。
業界・ビジネス要件によって異なる必要十分なセキュリティレベル
APIが扱うデータの性質を踏まえた上で、どの程度のセキュリティが必要なのかを考える必要があります。例えば、以下のようなケースでは求められるセキュリティレベルが異なります。
金融業界 / 医療業界
- 顧客の個人情報や決済情報、健康情報など、機密性・プライバシー性が非常に高いデータを扱う場合、強固な認証・認可方式、暗号化、通信経路のセキュリティ、厳格なログ監視・監査などが求められる
- これらの業界では、国や地域ごとに遵守する必要がある法的な案件も存在するため、非常に高いセキュリティ基準が要求される
その他SaaS系サービスやECサイト
- 顧客情報や決済データは扱うものの、業界固有の要件を満たすためというよりは、各社が定義したセキュリティレベルや、顧客と合意したサービスレベル合意(SLA)、ブランド価値を毀損するリスクなどを考慮したセキュリティ要件が中心となる
APIセキュリティを担保するための多様な手段
APIセキュリティを担保する手段は多岐にわたります。以下にその代表例を示します。
認証・認可方式：
- API Key： シンプルかつ実装が容易な反面、利用者やアクセス範囲の細かな制御、セッションやアクセス期限などの高度な管理が困難なケースが多い
- OAuth 2.0： スコープや有効期限の設定、トークン再発行など、APIアクセスをより細やかにコントロール可能な仕組みを提供
通信経路の保護：
- mTLS（相互TLS認証）： クライアントおよびサーバー双方が証明書を検証する、強固な接続認証
- VPN・専用線： 特定のクライアントのみがアクセスできる閉域網を構築
その他：
- IPアドレス制限： 特定の範囲からのアクセスのみ許可
- WAF（Web Application Firewall）： 特定の攻撃パターンや不正リクエストを検出・遮断
これらの要素をどう組み合わせるべきかは、事前に定めるセキュリティ要件や想定する脅威モデル、APIが行う処理のビジネスインパクトや事業リスクの大きさによって異なります。
セキュリティレベルを高めることで発生するトレードオフ
セキュリティレベルを可能な限り高めることは、一見安全で正しいことのように思えますが、必ずしも最適解ではありません。以下に発生しうるトレードオフを示します。
構築・運用コストの増大：
- 複雑な認証フローや証明書管理、鍵ローテーション、APIを提供する企業内部の開発・運用リソースを増加させる
開発者体験（DX）の低下：
- 過度に複雑な認証手順やアクセス制御は、APIを利用する顧客企業の開発者にとってAPIクライアントを開発するハードルを上げてしまう
- 開発者のAPIを利用するハードルが上がり、APIクライアントの開発が停滞することで、APIを提供する企業が意図したエコシステムの形成が難しくなる
将来的なビジネスの柔軟性の低下：
- 一旦過度に高いセキュリティレベルを顧客に約束してしまうと、後からそれを緩和することは困難になる
- 最初に構築された期待値や運用プロセスが「標準」となってしまい、そのレベルを下げることで顧客との信頼関係を損ねてしまうリスクがある
要求されるセキュリティレベルを満たすことが重要であることは前提としつつも、過剰なセキュリティレベルを担保することで、上記のようなトレードオフが発生しうることを理解して意思決定を行うことが重要です。どうしてもトレードオフが発生してしまう選択をする必要がある場合、それらのリスクを回避・軽減する仕組みも併せて設定することも検討しましょう。
公開APIの最初の顧客候補とのコミュニケーション
特に新しく公開APIを立ち上げる際、最初の顧客候補に対して、どこまでのセキュリティ基準を担保すれば使ってもらえるか、というヒアリングを行うことがあります。
初期段階で顧客と過剰な期待値を作ってしまうと、将来的な公開APIの顧客拡大においても、同様の期待値を担保する必要があり、ビジネス成長やエコシステムの構築に大きな影響を及ぼしかねません。ヒアリングでは以下のポイントを考慮すると良いでしょう。
必要最低限のセキュリティ要件を明確化：
- 顧客に対して漠然とした「強固なセキュリティ」を提案するのではなく、OAuth 2.0やmTLSなど、セキュリティレベルを高めるための具体的な候補を提示して、顧客が本当に必要とする要件を聞き出すことが重要
顧客社内のレギュレーションを確認：
- 顧客には自社で定められたセキュリティチェックシートや標準規格が存在する場合がある
- 事前にこれらを確認することで、「必須要件」と「任意要件」を切り分け、過剰な対策を避けることが可能
総じて、顧客が本当は求めていないセキュリティ要件に対してオーバーコミットをしてしまわないことが重要です。「顧客が本当に求めているもの」を正確に理解し、それに対して必要十分なセキュリティレベルを担保できるように心がけましょう。
おわりに
公開APIで担保すべきセキュリティレベルは、扱うデータの機密性や重要性、業界ごとの規制や慣習によって異なります。一方で、セキュリティレベルは「高ければ高いほど良い」わけではありません。適切なレベルを設計するためには、コスト、運用負荷、開発者体験、将来のビジネススピードや柔軟性に与える影響といったトレードオフを考慮する必要があります。
必要十分なセキュリティレベルを確保できる最小の要件を定義し、顧客に対する過度なオーバーコミットを避けることで、柔軟かつ持続可能なAPIの開発・運用体制を確立できます。それがエコシステムの長期的な発展を支える重要な鍵となります。安心して利用でき、かつ柔軟に拡張していくことができるAPIの構築を目指してみてください。
本メディアはAPI特化の開発会社であるECU株式会社が運営しています。記事についてのご質問やAPIに関するご相談・お問い合わせはお気軽にお問い合わせフォームまで。
