.png.c9b8f3e9eda461da3c0e9ca5ff8c6888.png)
1。序文
一般的に、安全性は運用および保守部門に属します。前の会社の運用およびメンテナンスディレクターと、毎日の安全作業をDevOpsに統合できるかどうかについて話しました。まもなく、私はさまざまな理由で去りました。 5月、彼は2018年にサードパーティの支払い会社に入社し、年の前半にさまざまな検査に費やしました。規制状況は深刻であり、主要な指導者は安全性（主に監督）の重要性を持ち、2019年のすべての部門の目標は安全に関連しています。支払い会社はさまざまな規制機関からの検査に直面する必要があるため、一部のセキュリティは比較的うまく行われています。ほぼ1年の会社に精通した後、アプリケーションのセキュリティが比較的弱いことがわかっています。業界のより良いソリューションのこの部分はSDLです。さまざまなメーカーと通信した後、私は会社で少しずつ宣伝することにしました。
上の写真は、SDLの標準バージョンを示しています。操作とメンテナンスはDevOpsシステムを採用しているため、テストでは機能テストにも自動化を使用します。バージョンの反復サイクルは比較的速く、セキュリティスタッフは不十分であり、SDLの脅威モデリングも混乱しています。プロセス全体に安全が追加された場合、それは配達時間に深刻な影響を与えます。この場合、業界のいくつかの慣行が調査され、SDLを簡素化することを決定しました。 SDLの簡素化されたバージョンは次のとおりです。
。
2。 Lite SDL実装練習
安全トレーニング
コアSDLの1つはセキュリティトレーニングです。そのため、セキュリティトレーニングの観点から、セキュリティコーディング、セキュリティ認識、セキュリティ知識ベース、セキュリティSDKを行いました。
安全コード：
Javaセキュリティコーディング仕様、製品セキュリティ設計および開発セキュリティの仕様がオンラインで、会社の実際のビジネスと組み合わせて、バージョンをリリースしました。
さまざまな規制機関にはトレーニングの要件があるため、安全トレーニングを導入し、開発と新しい従業員の採用のために定期的にトレーニングを受けています。
安全性認識：
同社は企業のWECHAT公式アカウントを持っており、ほとんどの従業員はそれに従い、公式アカウントで宣伝しています。
プロモーションが完了したら、小さな贈り物をください
スタッフが不十分であるため、機能テストと安全性テストは本質的に共通しています。テスト部門も比較的協力的であり、テスター向けの安全性テスト関連トレーニングを実施していますが、効果はあまり理想的ではありません。
安全知識ベース：
脆弱性修復プロセス中、多くの開発は原則と修復ソリューションを理解していないため、セキュリティ知識ベースを確立し、関連するソリューションをチェックするためにセキュリティ知識ベースに進みました。見つからない場合は、セキュリティ担当者と通信し、セキュリティ担当者は常に知識ベースを更新して閉ループを形成します。
セキュリティSDK
会社には建築部門があるため、開発フレームワークは基本的に建築部門によって提供されています。アーキテクチャ部門と共通の脆弱性を伝えた後、SDKを使用して建築に脆弱性修復方法を実装させます。開発には、JARパッケージをインポートして構成ファイルに構成する必要があります。また、多くの落とし穴があり、ゆっくりと最適化する必要があります。
3。安全要件設計
会社にはプロジェクト承認システムがあり、すべてのプロジェクトの承認はシステムを通じて確立する必要があります。安全性は必須であり、レビュー会議の安全性も参加する必要があります。
現時点では、プロジェクトマネージャーは基本的にセキュリティ担当者に連絡して通信し、VIP製品の安全設計仕様をコピーし、要件文書とプロジェクトマネージャーに基づいてセキュリティニーズを決定します。
セキュリティ要件を確認した後、必要に応じて要件ドキュメントに追加され、セキュリティテスト時間を確認します。このプロセスは、新しいプロジェクト専用です。開始されたプロジェクトの要件は、このプロセスに従うことはありません。その後のセキュリティテストでは、プロジェクトのこの部分がどのように行われるかについて説明します。
iv。開発、セキュリティテスト
セキュリティテストは、主にコード監査、脆弱性スキャン、および手動セキュリティテストに分割されています。これから派生した安全製品は、3つのカテゴリに分かれています。 DAST：Dynamic Application Security Test（WVS、AppScan）、SAST：Static Application Security Test（Fortify、RIPS）、IAST：Interactive Application Security Test（Seeker、Lijian）。これら3つの製品の詳細な紹介については、https://www.aqniu.com/learn/46910.htmlを参照してください。以下の図は、3つの製品のテスト結果の比較です。
これらのタイプの製品は自動化でき、DevOpsに継承できます。次に、これらのツールを開発テストフェーズに組み込みます。
IASTには多くの実装モードがあり、一般的なモードにはプロキシモード、VPN、トラフィックミラーリング、計装モードが含まれます。この記事では、2つの最も代表的なモード、プロキシモードと計装モードを紹介します。調査対象の製品の一部は以下の図に示されており、特定のテスト結果は発表されません。
開発段階
いくつかの種類の製品を調査すると、Iastの計装モードを開発環境に直接配置できます。開発環境とテスト環境のコードの主な違いは、Application.yml構成ファイルです。そのため、このモードは事前に開発段階に配置できます。
開発がコードの書き込みを完了し、GitLabに送信して開発環境に展開してアプリケーションを開始すると、開発は機能が利用可能かどうかを確認する必要があり、現時点では脆弱性があるかどうかを検出できます。
同社は、テスト環境で牧場主を使用し、Iast JARパッケージをプロジェクトのGitLabに入れ、展開中にコードをローカルに引いて、DockerFileファイルを変更してJARパッケージをコンテナに追加します。
シェル/xxx.jar/home/app/xx/libを追加します
会社のプロジェクトは基本的にSpring-Bootを使用しているため、すべてのプロジェクトはstart.shスクリプトを通じてアプリケーションを開始します。 start.shとdockerfileをプロジェクトのgitlabに追加し、start.shスクリプトファイルを同時に変更する必要があります。
-javaagent: $ app_home/lib/xx.jar -jar $ app_home/app/*。jar - spring.profiles.active=dev $ app_home/logs/startup.log 21
テスト項目は次のとおりで、タイプミスは無視されます。
開発および提出コードが展開されたら、通常の機能にアクセスすると、プラットフォームに脆弱性があるかどうかを確認できます。
一部の製品では、サードパーティのコンポーネントパッケージも検出されます。
同社は港を使用して倉庫として画像をミラーリングしています。プロジェクトが展開された後、ミラーにパッケージ化され、港にアップロードされます。ハーバーには、ミラースキャン機能が付属しています。
テストフェーズ
開発が完了した後、テスト段階に入ります。この段階では、静的コードスキャン、機能テスト、セキュリティテストを実施します。
静的コードスキャン
Static Code Scanningツールを使用して、コンパイル前にコードをスキャンし、セキュリティの問題を含む静的コードレベルでさまざまな問題を見つけます。いくつかのツールリスト：
静的コードスキャンSonarqube統合を使用し、FindBugseCurity、合理化されたルールを使用し、継続的な建設プロセス中に静的コードバグと安全なスキャンを実行します。
静的コードをスキャンしている間、サードパーティの依存関係パッケージもスキャンできます。 OWSAPの依存関係チェックは、連続的な建設プロセスに統合できます。 IASTクラスの製品はこの機能をサポートしているため、紹介しません。
機能テスト
機能テストの観点から、同社のテスト部門は自動テストプラットフォームを実装しています。初期段階では、エージェント検出を使用しませんでした。最初は、オープンソースのGourdscan Plus OpenRaspを使用し、デフォルトのOpenRaspを使用して、非インターセプトモードと脆弱性レコード関数を有効にして、サーバーで返されない脆弱性を検出しました。
自動化プラットフォームでプロキシIPを構成するだけです。
OpenRasp脆弱性レコード
その後、テストでは、汚れたデータスキャンが多すぎて効果があまり良くないことが報告されているため、この計画をあきらめました。 IASTの計装方法は開発段階で使用され、テスト環境ではエージェントも使用して、開発環境と同じ方法で問題を検出します。機能テストが完了した後。テスターは脆弱性をあまり理解していないため、指定されたプロセスは、テスターがプラットフォームにアクセスしてレポートとセキュリティ担当者を表示して、どの問題を修正する必要があるかを伝え、テストレポートに問題を記述することです。
安全テスト
テストフェーズ中にセキュリティがプロセス全体に追加されました。すべての要件の変更を完了する必要があり、機能テストが必要です。つまり、すべてのプロセスがセキュリティテストに合格しています。このようにして、セキュリティスタッフはそれほど十分ではありません。内部および外部サービスを区別する方法を使用して、介入するためにセキュリティ担当者が必要かどうかを判断することが決定されます。
脆弱性管理
脆弱性管理は脆弱性管理システムを策定し、脆弱性は影響の程度に応じて評価されます。重大な脆弱性を起動する前に修正する必要があります。高、中、低リスクの脆弱性には小さな影響があり、スケジュールする必要があります。セキュリティ担当者は、脆弱性修理の状況を定期的に追跡します。
v。監視
支払い会社には一般的にセキュリティ機器があります。この部分は基本的に、デバイスのsyslogをログセンターに使用して視覚化し、対応するルールをカスタマイズしてアラームを達成します。
vi。結論
個人の知識と経験は、SDLシステムにあまりよく知られておらず、経験がないため、現在のレベルにしか到達できません。将来、プロセスを最適化して追加する場所がたくさんあります。良い提案がある場合は、お気軽にお気軽にお問い合わせください
出典：https://xz.aliyun.com/t/5656