tubasa_gekituiのブログ

salesforce社の無料学習サイト「Trailhead」の覚え書きとか日記とか

Trailheadトレイル「セキュアな Web アプリケーションの開発」覚え書き

本記事は、トレイル「Develop Securely」の覚え書き、気づきの整理です。

trailhead.salesforce.com

サイバーセキュリティの柱、Webの脆弱性、脅威のモデル化、安全な開発ライフサイクルなどについて学ぶ話。 salesforce に限った話ではない、はず・・・。

Security Principles

Implement Security Fundamentals

  • 脆弱性を利用しようとしている悪意のある人物がたくさんいるのは事実ですが、最大のセキュリティ問題は自傷行為である傾向がある。自己負担のサイバーセキュリティの脅威 = 組織内から発生する脅威
    • 自傷行為の最も有害なタイプの1つは、変化によって引き起こされる事件。組織の変更管理基準に従って実施。
  • コード内に露出した認証情報は、専門家が報告する最もリスクの高いセキュリティ脆弱性の一つです。(Github に秘密の情報を登録しない)
  • セキュリティ3つの柱
    • Confidentiality (秘匿性) : 認可されていない個人、エンティティまたはプロセスに対して、情報を使用させず、また、開示しない特性。
    • Integrity(完全性) : 正確さ、および完全さの特性。
    • Availability(可用性) : 認可されたエンティティが要求したときに、アクセスおよび使用が可能である特性。

C.I.A.(Confidentiality, Integrity, Availability)とは - @IT

Learn the OWASP Top 10

  • OWASPは、Open Web Application SecurityProjectの略
  • バグバウンティプログラムは、システムで見つかったセキュリティの問題(またはバグ)を責任を持って開示するセキュリティ研究者に金銭的な報酬またはバウンティを提供する

Prevent Cross-Site Scripting and Injection Attacks

  • 外部攻撃は、組織のシステム外の誰かが損害を与えるために侵入することに成功。XSS が最も一般的で3種類ある。
  • XSS の軽減、入力フィルタリングと出力エンコーディングの2つの基本的な手法で対策する。
  • インジェクション攻撃:実行される正当なコマンドとして解釈される場合に問題が発生する。

Prevent Extensible Markup Language External Entity attacks

  • XXE : 外部エンティティ攻撃。
  • Extensible Markup Language(XML)は、ハイパーテキストマークアップ言語(HTML)によく似たマークアップ言語であり、データを格納および転送する。弱く構成されたXMLパーサーが外部エンティティへの参照を含むXML入力を処理するときに問題が発生する。
  • XXE攻撃を防ぐ最も安全な方法は、常にDTD(外部エンティティ)を完全に無効にすること
  • DTD : ドキュメントタイプ定義

Secure Your Organization’s Internal Resources

  • 内部リソースは、プロセス、ポリシー、および手順が組織の資産と顧客からの信頼を確実に保護するためにコードに組み込む安全機能。
  • 強力な認証メカニズム:パスワード管理の強化(MFA など)、パスワードの試行を制限する、冗長な失敗メッセージの回避
  • セッション管理:強力なトークンを使用する、トークンを安全に処理する
  • データの漏洩を防ぐ:そもそも機密データを保存しない(しても最小限)。最新の強力な標準アルゴリズムプロトコル、およびキーを使用。機密データを含む応答のキャッシュを無効。

Secure Development Lifecycle

Use a Secure Development Lifecycle

  • 安全な開発ライフサイクル(SDL):開発サイクルのすべての段階でセキュリティを統合。要件から設計、コーディングからテストに至るまで、プロセスのすべてのステップで製品またはアプリケーションにセキュリティを組み込む。
  • ライフサイクル7つのステージ: Learn, Design, Build, Verify, Release, Own, Reflect

Start With a Security Assessment

  • セキュリティ評価:脆弱性をチェックし、進行中のエンジニアリング作業をリスクのレベルでランク付け
  • security by design (SBD):組織のセキュリティを危険にさらす可能性のある欠陥の可能性を減らすために、最初から安全であるようにソフトウェアを設計すること

Practice Security by Design

  • 脅威をモデル化する:セキュリティの目的について合意。 → データフロー図を作成して、アーキテクチャを説明。 → 組織の資産と脆弱性を調べて、プロジェクトに対する脅威を特定。 → プロジェクトで見つけた脅威(可能性があり、検証済み)に対する緩和策を特定。 → プロジェクトの防御を構築して検証。
  • 安全に設計&構築するポイント:多層防御を適用、最小限の特権を使用、安全なデフォルトを使用、攻撃対象領域を最小限に抑える、ポジティブセキュリティモデルを使用 など。

Test and Verify Securely

  • セキュリティテストは2つのことを行う:システムの脆弱性を発見して修正する。システムのデータとリソースが侵入者から保護されていることを確認する。
  • 動的テストで検出できる脆弱性クロスサイトスクリプティングXSS)、SQLインジェクション、コマンドインジェクション、パストラバーサル、安全でないサーバー構成など
  • 静的解析:静的アプリケーションセキュリティテスト(SAST)ツールを使用し、脆弱性を早期に発見して修正することにより、時間とお金を節約。

Maintain Security Post Release

Threat Modeling Fundamentals

Learn Threat Modeling Fundamentals

  • 脅威モデリング:システムを分析してリスクを評価し、脅威を特定し、それらの脅威に対処するための緩和策を特定するための構造化されたアプローチ。
  • 脅威とは、意図的または偶発的に脆弱性(セキュリティの弱点またはギャップ)を悪用して、資産を取得、損傷、または破壊する可能性のあるもの。

Create a Threat Model

  • セキュリティ目標について合意 3つのステップ:システム資産を特定 → 攻撃者が何を求めているかを定義 → セキュリティの前提を特定。
  • データフローの作成:各ブロックコンポーネントの1つ(1つのエンティティ、1つの信頼境界、1つのプロセス、および1つのデータストア)から始める。簡単なストーリーや概要を書くことも、行き詰まった場合にデータフロー図を開始するのに役立つ。

Spot the Threats

  • ハッカー その種類:ハクティビスト(政治的な問題)、サイバー犯罪者(組織の資産を狙う)、サイバー戦士(権利維持?)
  • STRIDEニーモニック:Spoofing(なりすまし), Tampering(改ざん), Repudiation(否認), Information Disclosure(情報開示), Denial of Service(サービス拒否), and Elevation of Privilege(特権の昇格)。

Mitigate the Threats

  • 脅威への緩和策は全体的または部分的。特定したすべての脅威を体系的に処理することが重要。
    • 部分的な緩和策では、弱点となるリンクを作らないことが重要。攻撃者は往々にして、簡単なものから攻略しようとするため。
  • 脅威に対するプロジェクト判断:再設計とリスク受容。リスクを受け入れる正確なプロセスは、チームとテクノロジーによって異なり、エグゼクティブレベルの合意が必要。

salesforce 関係なく、一般の開発でも言えることを書かれていた内容かと。トレイル内のモジュールの間で内容が被っていることがあるので、おさらいの意味も兼ね日をまたいで消化したほうが良さげ。