APP / APP-05
APIアーキテクチャとセキュリティ実装
各クライアントが権限のあるデータとアクションにのみアクセスできるように、APIコントロールを設計または修正します。このプロジェクトでは、アイデンティティ、ビジネス認可、バリデーション、クォータ、トレーサビリティを対象としています。.
役立つとき
的確な回答
定義されたニーズに対して.
パートナーAPIのローンチ、テナントの分離、モバイルアプリケーション、ビジネス対ビジネスの統合、または認可上の脆弱性を明らかにした侵入テストなど。.
適用範囲と成果物
このエンゲージメントの対象範囲.
スコープ
- エンドポイントのインベントリ
- 認証
- オブジェクト/アクションレベルの権限
- 入力検証
- 秘密
- 使用制限
- ログ記録
- バージョン
- ポジティブ/ネガティブテスト
- パートナーの書類
成果物
- 承認モデル
- 設定と修正が合意されました
- 統合仕様
- 自動テスト
- クォータポリシー
- 取り消し手続き
- 操作マニュアル
検収証拠
ロールやテナントの切り替えテストは合格しました。不正な操作はサーバー側で拒否されます。秘密情報は取り消し可能で、クォータはテスト済みです。ログは不要なデータへのさられを伴うことなく有用です。.
配達
仕事の進め方.
アプローチ
アーキテクチャを理解する；リスクと要件を選択する；制御を統合または検証する；テストする；チームに引き渡す；回帰チェックの計画を行う。.
前提条件と責任
顧客：コード、アーキテクチャ、開発者、テスト環境、およびパイプラインへのアクセス。プロバイダー：専門知識とチェック。コードの修正は含まれている場合のみ。.
スコープ要因
アプリケーション、言語、リポジトリ、依存関係、ロール、パイプライン、ボリュームと深度。個別のツールライセンス、修復開発、保守。.
確認のための質問
APIを誰が呼び出し、どのアカウントで呼び出しているのか？データ所有権はどこで確認されるのか？他のユーザーを混乱させずにパートナーを削除する方法は？
重要な境界線
API ゲートウェイは必ずしもすべてのビジネス権限を把握しているわけではありません。制御は正しいレイヤーで動作する必要があります。有効なトークンはすべてのデータへのアクセスを許可するわけではありません。.
管理策は、合意されたバージョンおよびスコープに適用されます。スキャナー、SBOM、フレームワークのいずれ単体でも、納品されるソフトウェアのセキュリティを保証するものではありません。.
実際には
具体例.
これらの例は、想定される関与と目標とする成果について説明したものであり、顧客の事例や達成された実績ではありません。.
シナリオ01
ポータルにより複数のパートナーが注文を閲覧できます。 プロジェクト：オブジェクトレベルの承認を強制し、分離テストを実施。 ターゲットアウトカム：各パートナーは、リクエストで提供された識別子に関わらず、注文のみを確認できます。.
シナリオ 02
モバイルアプリは過度に強力な共有キーを使用しています。 プロジェクト：アイデンティティの再設計とサーバーサイドのアクセス権限の制限。 ターゲット成果：アクセスを追跡可能かつ取り消し可能にする；アプリにキーを単に隠すこと自体では十分な保護とは認められません。.
技術と参照コンテキスト
参考文献：OWASP API Security and ASVS;アーキテクチャに依存することなく、ブランドに依存しないアイデンティティソリューションとゲートウェイ。.
最終的なテクノロジーセットは、相互運用性、ライセンス、アクセス権、および運用要件に基づき、スコープ設定の段階で合意されます。.
コネクテッドサービス
次のステップを構築する。.
これらのサービスはエンゲージメントを補完するものであり、自動的には含まれません。.
会話を始めましょう。
スコープを明確にする。.
このサービスの目的、依存関係、および責任範囲を明確にした上で、納品を提案いたします。.