API の保護

開発者は API を採用していますが、それには正当な理由があります

api-protection

API が登場したことによって、アプリケーションの開発方法や業務の進め方が変わりました。API を利用すると、API 呼び出し経由で多数の共通または共有モジュールを統合することができるので、開発が容易になります。加えて、製品を市場に投入するまでの時間も短縮されます。また開発者は、「既に発売されている」質の高いコモディティ (一般的な) 機能や、時として複雑な機能を接続することもできます。API がなければ、その機能を自力で一から開発しなければならない場合もあります。

API は戦略上の価値が高いので、API が採用される場面は予想以上のペースで増加しています。API が急速に普及するにつれて、それに由来するセキュリティのリスクも高まってきました。

API は対処が必要な新たなリスクももたらす

API にはこのように数々の利点がありますが、ハッカーからも便利に利用できるという、新たなリスクを負うことになります。ここに示したビデオでは、以下を説明しています。

  • API はどのような働きをするのかについて、ハイレベルな説明をしています。
  • ハッカーが API を悪用して、バックエンドのサーバーに置かれている、機密性の高いデータやアセットへのアクセスを獲得する方法の概要を説明しています。
  • API を総合的に保護するために利用できるコントロールについて説明します。

このビデオのスクリプト (音声の文字起こし) をご覧になるには、ここをクリックしてください

モバイル アプリを開発する際のスピードやアジリティ (俊敏性) を重視して、API を採用している企業は多い。ただし、接続の安全性を確保するためにセキュリティ制御の仕組みを追加している企業は多いとはいえない」– 451 Research (調査会社) の情報セキュリティ担当リサーチディレクター、Scott Crawford

モバイル アプリに対する不正スキャンの 79 %は、API の悪用によるものだった – HPE サイバーリスクリポート 2016 年版

汎用的な API による保護は、大半の API 管理ソリューションに含まれている単純な認証機能を超える部分をカバーしている

api-protection

単純な認証は、大半の API 管理ソリューションで広範囲に利用されていて、この認証によって、モバイル デバイスに展開されているクライアント アプリが正規のもので、サーバー アセットを利用する権限があることを確認します。この操作は通常、クライアント アプリが API サーバーへの接続を試みて、単純にチャレンジ/レスポンスを交換することによって実行されます。チャレンジ/レスポンスの交換は通常、暗号化したうえで実行されます。言い換えると、一般的にモバイル クライアントには、RSA や ECC などの非対称のサイファーの秘密鍵が含まれています。

上記の短いビデオで説明しているとおり、このアプローチにはまだ、ハッカーの侵入を許す余地が多数残されています。そこで業界のリーダー各社は、単純なチャレンジ/レスポンスに基づく認証を実行するだけでなく API の包括的なセキュリティ対策を採用して、API に付随するリスクを軽減しています。そうした対策を以下に示します。

cryptokey ステップ 1: ホワイトボックス方式の暗号化を使ったセキュアな認証

ホワイトボックス方式の暗号化とは、たとえハッカーがそのソフトウェアへのフル アクセス権限を取得してしまったとしても、暗号鍵を安全な場所に隠すための仕組みです。

– オリジナルの暗号鍵は、落とし戸関数 (一方通行で不可逆的な関数) を使って別の形に変換されます。

– 変換後の鍵の新しい形式は、その鍵と関連付けられたホワイトボックス方式の暗号化ソフトウェアでのみ使用されますが、このソフトウェアが暗号鍵を隠ぺいします。

– ホワイトボックス方式の暗号化ソフトウェアを使うと、ハッカーはチャレンジ/レスポンスで使用している暗号鍵を見つけることができなくなります。

ただしここまでやっても、まだ十分ではありません。ホワイトボックス方式の暗号化では鍵を安全な場所に隠ぺいします。ところがハッカーはそれでも、元のアプリケーションを逆コンパイルしてアプリを改変したり、あるいはホワイトボックス方式の暗号化ソフトウェア パッケージを丸ごと盗み出し、アプリケーションのクローン バージョンにそのパッケージを含めたりするかもしれません。

ステップ 2: コードの改変をしにくくする技法を採用し、コードを登用する攻撃やアプリの改ざんを防止

コードの改変をしにくくする技法には、RASP (Runtime Application Self-Protection: 実行中のアプリケーションが自身を保護すること) も組み込みますが、アプリ実行中の (ランタイム) 攻撃に対して、システムの状況に応じてカスタマイズした動作を実行し、同時にアプリの所有者に対して、アプリが改変されたことを通知します。