インド CERT-In APIセキュリティ：脅威、ベストプラクティス、課題、そしてAIを活用した前進への道 (2023.08.14)

こんにちは、丸山満彦です。

マスターカードがサポート？して、インドの金融CERTと、CERTインドが、 APIセキュリティ：脅威、ベストプラクティス、課題、そしてAIを活用した前進への道というホワイトペーパーを公表していましたね。。。（8月...）

インドの金融機関では、圧倒的 (57%) にセキュリティの誤設定が攻撃をうける原因となっているようですね。。。

これから、クラウド中心でしょうし、疎結合でしょうし、色々と参考になりますね。。。

最後はAIについても触れられていますね。。。

● CERT-In

・2023.08.14 API Security: Threats, Best Practices, Challenges, and Way forward using AI

・[PDF]

・[DOCX] 仮訳

目次...

Introduction	はじめに
API Usage Landscape	APIの利用状況
API Threat Landscape	APIの脅威の状況
API Threat Landscape in Indian Financial sector	インドの金融セクターにおけるAPI脅威の状況
Type of API Attacks	API攻撃の種類
Limitations of traditional methods	従来の方法の限界
API Gateways and their Limitations:	APIゲートウェイとその限界：
WAF’s and their Limitations:	WAFとその限界：
AI & API Security	AIとAPIのセキュリティ
AI vs Rule based Security	AIとルール・ベースのセキュリティ
How AI Based API security works:	AIベースのAPIセキュリティの仕組み
Challenges in using AI Based models in API Security:	APIセキュリティにおけるAIベースのモデル使用の課題：
Current to Future	現在から未来へ
Conclusion	結論
Appendix	附属書

API攻撃の種類とインドの金融機関における割合

API攻撃の種類		%
Broken Access Control allows an unauthorized user access to restricted resources.	穴のあるアクセス制御は、権限のないユーザーが制限されたリソースにアクセスすることを可能にする。
Cross site scripting attacks are a type of injection, in which malicious scripts are injected into trusted websites.	クロスサイト・スクリプティング攻撃はインジェクションの一種で、信頼できるウェブサイトに悪意のあるスクリプトが注入される。	1%
SQL Injection uses malicious SQL code for backend database manipulation to access information that was not intended to be displayed.	SQLインジェクションは、悪意のあるSQLコードを使用してバックエンドのデータベースを操作し、意図しない情報にアクセスする。	3%
Excessive Data Exposure is when too much information passes from the API to the client, with the client filtering what information is displayed to the user.	過剰なデータ露出とは、APIからクライアントへ渡される情報が多すぎることで、クライアントはユーザーに表示される情報をフィルタリングしている。	3%
DDoS attack disrupts the normal traffic by overwhelming the target infrastructure with a flood of Internet traffic.	DDoS攻撃は、インターネット・トラフィックの洪水で標的のインフラを圧倒することで、通常のトラフィックを混乱させる。	34%
MITM is when a perpetrator is in between a user and an app -either to eavesdrop or to impersonate one of the parties.	MITMとは、犯人がユーザーとアプリの間に入り、盗聴したり、どちらかの当事者になりすましたりすることである。	2%
Security misconfiguration is when security options are not defined in a way that maximizes security, or when services are deployed with insecure default settings.	セキュリティの誤設定とは、セキュリティ・オプションがセキュリティを最大化する方法で定義されていない場合や、サービスが安全でないデフォルト設定のまま配備されている場合である。	57%

APIセキュリティのベストプラクティス...

1.  Authentication and Authorization	1. 認証と認可
• Use strong authentication mechanisms such as API keys, OAuth, or JWT (JSON Web Tokens).	• APIキー、OAuth、JWT（JSON Web Tokens）などの強力な認証メカニズムを使用する。
• If using tokens like JWT, set appropriate expiration times and implement secure token management practices to prevent token misuse or replay attacks.	• JWTのようなトークンを使用する場合は、トークンの誤用やリプレイ攻撃を防ぐために、適切な有効期限を設定し、安全なトークン管理を実施する。
• Implement granular access control to limit API access based on user roles and permissions.	• ユーザーの役割と権限に基づいてAPIアクセスを制限する、きめ細かなアクセス制御を実装する。
• Always validate user credentials and tokens before granting access to sensitive data.	• 機密データへのアクセスを許可する前に、必ずユーザー認証情報とトークンを検証する。
2.  API Gateway and Firewall:	2. APIゲートウェイとファイアウォール：
• Employ an API gateway for centralized security enforcement, monitoring, and management.	• 一元化されたセキュリティの実施、監視、管理のためにAPIゲートウェイを採用する。
• Implement web application firewall (WAF) to protect against common web threats.	• ウェブアプリケーションファイアウォール（WAF）を導入し、一般的なウェブの脅威から保護する。
3.  Data Protection and Secure Communication:	3. データ保護と安全な通信：
• Encrypt sensitive data using appropriate encryption algorithms and key management.	• 適切な暗号化アルゴリズムと鍵管理を使用して機密データを暗号化する。
• Apply data masking techniques to hide sensitive information in logs and responses.	• ログやレスポンスに含まれる機密情報を隠すために、データマスキング技術を適用する。
• Use secure communication protocols to prevent eavesdropping and manin-the-middle attacks.	• 盗聴や中間者攻撃を防ぐため、安全な通信プロトコルを使用する。
• Employ secure headers and practices to prevent information leakage.	• 情報漏洩を防ぐため、安全なヘッダーと慣行を採用する。
4.  Input Validation and Sanitization	4. 入力検証とサニタイズ
• All user inputs should be validated and sanitized to prevent injection attacks (e.g., SQL injection, XSS) and parameter manipulation.	• インジェクション攻撃（例：SQLインジェクション、XSS）やパラメータ操作を防ぐため、すべてのユーザー入力は検証され、サニタイズされるべきである。
5.  Output Encoding	5. 出力エンコーディング
• Encode output to protect against HTML/JavaScript injection (XSS) and other data manipulation attacks.	• HTML/JavaScriptインジェクション（XSS）やその他のデータ操作攻撃から保護するために出力をエンコードする。
6.  Rate Limiting and Throttling	6. レート制限とスロットリング
• Implement rate limiting and throttling mechanisms to prevent abuse of the API and DDoS attacks by limiting the number of requests from a single client within a specific time frame.	• 特定の時間枠内での単一クライアントからのリクエスト数を制限することで、APIの悪用やDDoS攻撃を防ぐために、レート制限とスロットリングのメカニズムを実装する。
7.  Error Handling and Logging	7. エラー処理とログ
• Ensure proper error handling to avoid exposing sensitive information.	• 機密情報の漏洩を防ぐため、適切なエラー処理を行う。
• Implement comprehensive logging for monitoring and auditing purposes.	• モニタリングと監査を目的とした包括的なロギングを実施する。
8.  CORS (Cross-Origin Resource Sharing)	8. CORS（クロスオリジンリソース共有）
• Configure CORS properly to restrict which domains can access the API from the client-side, thereby preventing unauthorized cross-origin requests.	• CORSを適切に設定し、クライアント側からAPIにアクセスできるドメインを制限することで、不正なクロスオリジン・リクエストを防ぐ。
9.  Secure Storage of Secrets	9. 秘密の安全な保管
• Store API keys, credentials, and sensitive data securely using encryption and access controls.	• 暗号化とアクセス制御を使用して、APIキー、認証情報、機密データを安全に保存する。
10. Regular Security Assessments	10.定期的なセキュリティ評価
• Conduct regular security assessments of APIs such as penetration testing, security audits and code reviews to identify potential vulnerabilities and security flaws.	• 侵入テスト、セキュリティ監査、コードレビューなど、APIの定期的なセキュリティ評価を実施し、潜在的な脆弱性やセキュリティ上の欠陥を特定する。
11. Education and Documentation	11.教育と文書化
• Clear documentation should be provided containing steps to use the API securely, including examples of proper authentication and authorization methods.	• 適切な認証および認可方法の例を含め、APIを安全に使用するための手順を含む明確な文書を提供すべきである。
12. Privacy Protection	12.プライバシー保護
• Minimize data collection and storage to only what is necessary.	• データの収集と保存を必要なものだけに絞る。
• Comply with relevant privacy regulations and obtain user consent for data processing.	• 関連する個人情報保護規則を遵守し、データ処理についてユーザーの同意を得ること。
• Integrate privacy considerations from the initial stages of API development. Perform a Privacy Impact Assessment (PIA) to identify and mitigate potential privacy risks.	• API 開発の初期段階からプライバシーに配慮する。プライバシー影響評価（PIA）を実施し、潜在的なプライバシーリスクを特定・軽減する。
13. Secure Development Lifecycle (SDLC)	13.セキュア開発ライフサイクル（SDLC）
• Integrate security considerations into the entire API development process.	• セキュリティへの配慮をAPI開発プロセス全体に組み込む。
• Conduct security training for developers to raise awareness of secure coding practices.	• 開発者向けにセキュリティトレーニングを実施し、セキュアコーディングの実践に対する意識を高める。

---

API Security

● まるちゃんの情報セキュリティ気まぐれ日記

・2023.08.19 ロシア 科学技術センター ：新たなサイバーセキュリティの脅威

・2022.01.04 NISTIR 8389（ドラフト）オープンバンキング技術と先端標準に関するサイバーセキュリティ上の考慮事項

・2021.09.15 Cloud Security Alliance 安全なサーバーレス・アーキテクチャをどう設計すればよいか

・2021.08.17 ロシア 連邦中央銀行が金融取引におけるクライアント認証のセキュリティ標準を発行

・2021.05.01 Cloud Security Alliance APIを提供・利用するためのセキュリティガイドライン