API セキュリティのためのベスト・プラクティスを策定する

Developing Best Practices for API Security

2021/08/03 SecurityBoulevard — デジタル・トランスフォーメーションの全体的な成功において、API は欠かせないものだ。API を利用することで、デジタル資産や複数のシステムの開発が容易になる。Google のレポートによると、より多くの組織が API イニシアチブを採用し、API ファーストの姿勢でデジタル・トランスフォーメーションに取り組んでいる。このレポートによると、「58％は、上位の API イニシアチブにより、新規のアプリケーション開発のスピードを向上させる。

47％ は、コア API プロジェクトの中に、開発者プラットフォームの作成を取り込む。 32％ は、API を用いて B2B パートナー・プログラムを開発する。 そして 10％は、新しい収益源のロックを解除するための API マネタイジングにフォーカスする」と述べている。しかし、API の利用が増えればセキュリティ・リスクも高まるが、その主たる理由は、モバイルで利用するための API セキュリティに、開発者が適合できないからだ。また、設計や開発の段階で、セキュリティのベスト・プラクティスに従わない開発者が多いことも挙げられる。

API セキュリティの２つのレベル

API セキュリティのベスト・プラクティスを構築するためには、組織特有のセキュリティ上の問題点の場所を、開発者が深く理解する必要がある。EPAM Systems の Chief Information Security Officer である Sam Rehman は、電子メールによるインタビューにおいて、API セキュリティのベスト・プラクティス・リストを考案／作成する際に考慮すべき具体的な領域として、戦略／設計レベルと戦術レベルの２つがあると述べている。Rehman は、「戦略／設計レベルでは、API はアクセスと再利用性を優先する。API であれば、たとえば車輪を再発明する必要もなく、すでに構築されたものを別の状況で利用できる。そして、すでにテストされ、スケールアウトされ、願わくば適切に管理されたレイヤの上で、新たに構築していくことが可能になる」と述べている。

API の設計者は、多目的な API 利用を目指して柔軟性を持たせるため、コアとして多くの機能やアクセス・ポイントを提供するよう注力する。また、新機能を提供するために必要な、絶え間ない変更やアップグレードも考慮して、API の設計を行う必要がある。Rehman は、「このような柔軟性は、多くの人にメリットをもたらすが、その一方で複数のエントリー・ポイントや幅広い攻撃領域をもたらし、攻撃者がシステムを悪用する機会を増やす。戦略／設計レベルでは、柔軟性と攻撃の機会は相反するものとなる」と述べている。戦術的なレベルでは、Volume および、Chattiness、Data Leakage、Bi-Directional authN などの領域が、セキュリティ実装を困難にする要因となる。

脅威の認識

API のセキュリティを向上させるためには、開発者はどのような種類の脅威に対処すべきなのかを、開発者が知る必要がある。Rehman は、API のセキュリティに関する脅威のリストを提示しているが、包括的なものではないと付け加えている。

・脆弱な authN (AutheNtication) とauthZ (AuthoriZation)：脆弱な authN は、特にサービス間で頻繁に見られるものだ。API キーは多くのレイヤーの１つとして機能すべきであり、唯一の手段であってはならない。API キーはローテーションされ、そのライフサイクルは厳密に管理されなければならない。アクセス・トークンは短期的なものであり、頻繁に変更する必要がある。最後に、アクセス権は下位から与え、必要なときだけ昇格させるべきだ。
・成りすまし／クレデンシャル・スタッフィング／ボット／ゴースト・アカウント： クレデンシャル・スタッフィングやゴースト・アカウントなどのサイバー攻撃の手法は、オンラインのEコマース・プロバイダーにとって明らかな脅威であるが、あらゆる API/SaaS プロバイダーにも当てはまる脅威である。
・スマート・スキャナー：API レベルでは、アクティブで容易に利用できる数多くのスキャナーがあり、攻撃者に選択肢を与え、攻撃の視点を探すスピードが上がっている。コンテキストや機械学習 (ML) を利用したスマート・スキャナーも多く、攻撃者の生産的は更に向上している。
・インサイド・アウトのみの観点：多くの API は、未だにインサイド・アウト (防御)の視点でテスト／設計されている。API を最強のものにするためには、ユーザーの視点、さらに言えば、攻撃者の視点で見る必要がある。
・デバイス・セキュリティ： API が誰と通信しているかを知り、その可視性を判断することが重要である。セキュア・チャネルは必須だが、モバイル・デバイスが広く開放されていて、特権アクセスを可能にする悪意のソフトウェアが存在する場合には、攻撃者によるデータ流出やコール・ハイジャックなどが、簡単に実行されてしまう。

ベスト・プラクティス

開発ライフ・サイクルにおけるセキュリティ上の問題点と、対処すべき脅威を把握した上で、開発者はベスト・プラクティス・リストの作成を開始する。最初のセキュリティ・ベストプラクティスは、常に組織のニーズと関心により決定されるが、すべての開発者が従うべき重要なものとして、次の項目があると、Rehman は考えている。

・セキュアな ID を明確にし、RBAC (Role-based access control) を組み合わせ、ABAC (Attribute-based access control) を使って Control/authR を微調整しながら強化していく。
・より小さく、よりコンテキスト・ドリブンな呼び出しを行うことで、防御層が攻撃者に対してより効果的になり、攻撃の影響を減らすこと になる。
・ゼロトラスト原則を考慮する。
・公開されている API コールを制限し、呼び出し元を新しい API に移動させ、使用されていないコールを積極的に監視して廃棄する。また、開発者はデバイス・チェックを行い、コールのサブセットとバージョンを可能な限りバインドする。
・攻撃を理解するセキュリティ専門家と共に API デザインをレビューし、ギャップを発見する。機能をテストするためには、ブラックボックス・テストとグレー・ボックステストの両方を完了する必要がある。

API のセキュリティは難しい。従うべき標準はなく、個々の API の独自性も考慮しなければならない。しかし、セキュリティ上の問題点が、どこにあるのかを理解し、ベスト・プラクティス標準を策定すれば、セキュリティを後回しにする必要はなくなる。

こういう記事は、authN / authZ / RBAC / ABAC といった用語が、注釈もなく並んでいるので、訳そうと思っても固まります。まずは、それらを検索して、自分なりに意味を把握してからの翻訳となりますが、無事にゴールできてホッとしています。それにしても、最近は API に関する、この手の記事が多いです。しかも、それぞれの記事の切り口が違うので、専門家のレベルでも手探りの部分があるのでしょう。