mcpField
O
oh-distributed-security-design-review

oh-distributed-security-design-review

github.com/openharmonyinsightセキュリティ3586 回インストール11 週間前に更新
リポジトリ

oh-distributed-security-design-review について

OpenHarmonyの分散システムコードを対象に、安全性レビューの規則と手順を示すスキルです。18項目の設計ルールと一般的なセキュリティ確認を組み合わせ、問題点と修正案をまとめる方法を案内します。

主な機能

  1. 0118項目のセキュリティ設計ルール
  2. 02業務コンテキストに応じたルール選定
  3. 03通信する双方のコードをレビュー
  4. 04違反事項と修正案の報告

活用シーン

  1. 01デバイス間の認証・認可実装のレビュー
  2. 02機密データ転送と信頼関係の確認
  3. 03分散ステートマシンとリソース管理の検査

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/openharmonyinsight/openharmony-skills --skill oh-distributed-security-design-review

インストール後、Claude Code で/oh-distributed-security-design-reviewを入力して読み込まれたか確認します。

同梱ファイルreferences/security_rules.md

詳細

OpenHarmony 分散システムのセキュリティコードレビュー用スキル

概要

このスキルでは、OpenHarmony の分散型業務におけるセキュリティコードレビューの専門的なガイダンスを提供します。18 項目のセキュリティ設計ルールと、対応するレビューのチェックポイントが含まれています。分散システムのコードのセキュリティをレビューする際は、一般的なサイバーセキュリティのルールに加えて、これらのルールを用いてレビューを強化します。

トリガーフレーズ

  • 「コードのセキュリティ実装をレビュー」
  • 「コードセキュリティレビュー」
  • 「セキュリティコードレビュー」
  • 「このコードのセキュリティを確認」
  • 「分散コードのセキュリティをレビュー」
  • 「OpenHarmony セキュリティレビュー」

コードレビューワークフロー

Step 1: コードのコンテキストを理解する

まず、コードの業務シナリオと所属するモジュールを理解します。

  1. 主要モジュールの特定: コードが以下のモジュールに関連するかどうかを確認します

    • 分散デバイス管理
    • 分散ソフトバス
    • その他、分散機能を必要とするモジュール
  2. 業務の種類の特定: 以下のセキュリティ上重要な業務に関連するかどうかを判断します

    • デバイス間の認証と認可
    • ユーザーの機密データの転送
    • デバイス間のステートマシン管理
    • 信頼関係の管理
    • ハードウェアリソースへのアクセス
  3. 役割の特定: コードが主体側(クライアント)か、客体側(サーバー)かを特定します

Step 2: セキュリティルールを読み込む

コードが関わる業務の種類に応じて、security_rules.mdから該当するルールを読み込みます。

キーワードのクイック索引:

  • デバイス間転送 → Rules 3, 8, 15, 17
  • ステートマシン → Rule 2
  • 認可/認証 → Rules 1, 5, 6, 8, 12
  • PIN コード/秘密鍵 → Rules 3, 8, 9, 10
  • リソース要求 → Rule 4
  • 権限設定 → Rules 7, 13
  • スイッチフラグ → Rule 14
  • ユーザー切り替え → Rule 16
  • 互換コード → Rule 18
Step 3: セキュリティルールに照らしてレビューする

適用される各セキュリティルールについて、以下のレビューを実施します。

  1. 関連コードの特定: Grep を使って重要なパターンを検索します

    Grep patterns examples:
    - "auth", "authorize", "permission" for authorization checks
    - "PIN", "secret", "key" for sensitive data
    - "state", "status" for state machine
    - "random", "generate" for secret generation
    
  2. 実装の詳細を確認:

    • ルールのチェックポイントを一つずつ確認します
    • 潜在的な違反パターンを探します
    • 欠けているセキュリティ対策を特定します
  3. 発見事項を記録:

    • 違反コードの位置(file:line)を記録します
    • 違反している具体的なルールを説明します
    • 修正案を提示します
Step 4: 一般的なセキュリティのベストプラクティスを適用する

OpenHarmony 固有のルールに加え、一般的なセキュリティ対策も確認します。

  1. 入力検証: すべての外部入力が検証されているか
  2. エラー処理: 機密性の高い操作に適切なエラー処理があるか
  3. ログの安全性: 機密情報が記録されていないか
  4. リソース管理: リソースリークのリスクがないか
Step 5: レビューレポートを作成する

以下を含む、構造化されたセキュリティレビューレポートを作成します。

  1. エグゼクティブサマリー: 発見した重大なセキュリティ問題の件数と深刻度
  2. 違反一覧: 深刻度順に並べた違反項目
  3. ルールとの対応付け: 各問題に対応するセキュリティルール
  4. 修正案: 具体的なコード変更の提案

よくある違反パターン

パターン 1: クライアント制御の認可(ルール 1 違反)

悪い例:

// 客体侧直接使用主体侧传入的标志控制弹框
void handleAuthRequest(bool showPopup) {
    if (!showPopup) {
        // 直接跳过授权弹框
        grantAccess();
    }
}

適切な方法:

// 客体侧独立决策是否需要授权
void handleAuthRequest() {
    if (isSystemBusinessAndRegistered()) {
        // 已注册的免授权业务
        grantAccess();
    } else {
        // 默认必须弹框
        showAuthorizationDialog();
    }
}
パターン 2: 機密データの平文送信(ルール 3 違反)

悪い例:

// 明文传输PIN码
message.pin_code = userPin;
sendToRemote(message);

適切な方法:

// 加密后传输
encryptedPin = encryptPin(userPin, sessionKey);
message.encrypted_pin = encryptedPin;
sendToRemote(message);
パターン 3: 独自の信頼性検証(ルール 8 違反)

悪い例:

// 自行比对账号信息判断可信关系
bool isTrusted() {
    return localAccount == remoteAccount;
}

適切な方法:

// 依赖HiChain查询
bool isTrusted() {
    CredentialType type = HiChain.queryCredentialType(remoteDevice);
    return type == CredentialType.SAME_ACCOUNT;
}
パターン 4: 安全でないスイッチのデフォルト値(ルール 14 違反)

悪い例:

// 默认值放通
bool enableSecurityCheck = true;  // 默认启用

適切な方法:

// 默认值禁用
bool enableSecurityCheck = false;  // 默认禁用,需显式启用

セキュリティルールのカテゴリ

1. 認可と認証
  • Rule 1: 客体側での認可制御
  • Rule 5: ブルートフォース攻撃対策
  • Rule 6: サーバー側のセキュリティロジック
  • Rule 12: 機密データの認可と監査
2. データ保護
  • Rule 3: 機密データを平文で送信しない
  • Rule 10: 安全なランダムシークレット
  • Rule 17: 業務レベルの鍵の分離
3. 信頼管理
  • Rule 7: 信頼関係のライフサイクルを最小限にする
  • Rule 8: 信頼関係の検証
  • Rule 9: 信頼関係の永続化タイミング
  • Rule 15: デバイスの正当性検証
  • Rule 16: 分散型の信頼におけるユーザー分離
4. ステートマシンとプロセス制御
  • Rule 2: ステートマシンのコンテキスト検証
5. リソース管理
  • Rule 4: リソースアクセスパラメーターの検証
  • Rule 11: リソースのクリーンアップ
  • Rule 13: 最小権限の設定
6. コード品質
  • Rule 14: スイッチの安全なデフォルト値
  • Rule 18: レガシープロトコルの整理

レビューセッションの例

ユーザーの依頼: 「この分散デバイス管理コードのセキュリティをレビュー」

レビューの手順:

  1. セキュリティルールを読み込む → security_rules.mdを読む
  2. 関連ルールを特定する → Rules 1, 2, 7, 8, 9, 11(デバイス管理関連)
  3. コードパターンを検索する → 認可、信頼性、ステートマシンを Grep で検索
  4. 各ルールを確認する:
    • ✓ Rule 1: 認可フローが客体側で独立して制御されているか
    • ✗ Rule 2: ステートマシンでコンテキストが検証されていないことを発見
    • ✓ Rule 7: 信頼関係のライフサイクルが適切に管理されている
    • ✗ Rule 8: 独自の信頼性判定ロジックを発見
  5. レポートを作成する → 違反箇所と修正案を一覧表示

ヒント

  1. キーワードから始める: security_rules.mdのキーワードを使って、疑わしいコードを素早く特定します
  2. 両側を確認する: 分散型業務では、主体側と客体側の両方のコードを確認する必要があります
  3. フロー全体を検証する: 業務フロー全体を追跡し、単一の関数だけを確認しないでください
  4. エッジケースを考慮する: エラー処理、タイムアウト、リトライなどの境界条件を確認します
  5. ログを確認する: ログから機密情報が漏えいしないようにします

リソース

  • 詳細ルール: すべてのルールの説明とチェックポイントについては、security_rules.mdを参照してください
  • クイックリファレンス: ルールを素早く検索するには、security_rules.mdの末尾にあるキーワードマッピングを使用してください

コメント