search

Protocol

hashtag
Overview（概要）

本プロトコルはODS-RAMにおけるロギング機能を定義する。 ロギング機能は、通信ログ、サービスログ、処理ログの3つのカテゴリに基づき、システムの通信状況、各サービスの処理結果、全体の監視・運用状況を包括的に記録・分析可能とすることを目的とする。各ログは、それぞれ異なる保持要件、セキュリティ要件、および用途に基づき設計・運用される。

hashtag
Abstract Normative Specification（抽象仕様）

  • shall: ロギング機能はOpen Dataspacesの構成要素において発生する記録が求められる事象について、その事象の要件に基づく5W1Hの情報を付加して記録する機能を一貫して提供しなければならない。

  • should: ログの記録においては、情報を適切に保護する仕組みを取り入れ、特に機密性の高い情報については改ざん防止等の処理を実施する仕組みを提供することを原則とする。

  • should: ログへのアクセスは標準化されたインタフェースにより一貫したアクセス手段が提供されることを原則とする。

hashtag
Concepts and Roles（概念および役割）

本プロトコルにおけるログ機能では、ロールをシステム管理者、セキュリティ管理者、開発者、監査担当者に分類して、ログを通信ログ、処理ログ、サービスログに分類する。各カテゴリごとに役割と対象情報を定義して多様なシステム運用や監視ニーズに対応する指針を示す。

本プロトコルに必要な概念は以下である。

概念
説明

Data Provider（データ提供者）

データ利用者に対してデータストアに格納されたデータを送信する主体

Data Consumer（データ利用者）

データ提供者からデータを受信する主体

ロギングではログを以下3つのカテゴリに分類する。

  • 通信ログ: ODSを通過するメッセージ（例: リクエスト、レスポンス）やヘッダー情報を記録する。トラフィックや接続状況の監視、および異常検知を目的とする。

  • 処理ログ: リアルタイムダッシュボードや運用監視ツールを通じて、システム全体の処理状況、エラー状況、リソース利用状況などの監視・運用改善を目的とする。

  • サービスログ: 個別の連携サービスやAPIの処理結果の記録を目的とする。サービスログにはユーザの処理内容や機密情報が含まれる場合があり、特定の情報については適切な保護が求められる場合がある。

各ログの想定される用途は以下の通り。

  • 通信ログ

    • トラフィックと接続状況の監視

    • 異常通信のチェック

    • トラブルシューティング

    • 規制準拠状況の記録確認

  • 処理ログ

    • システム全体の処理状況の監視

    • エラー検知と対策

    • パフォーマンス分析

    • 内部運用ルールへの準拠確認

  • サービスログ

    • 連携サービスの稼働状況の把握

    • 機密情報の適切な保護の確認

    • APIやサービスの処理結果の分析

    • 処理内容の証跡確認

hashtag
Scope（適用範囲）

本ロギング機能は、それぞれのカテゴリごとに以下の情報を対象とする。 通信ログ・サービスログについては、ユーザーの個人情報や処理内容が含まれる可能性があるため、適切な保護が必要となる場合がある。

ODSシステムが処理する通信情報（通信ログ）:

  • ODSを通過するメッセージのリクエストおよびレスポンスを対象とする。

  • メッセージのボディに加えメタデータ（例: HTTPメソッド、HTTPヘッダー、ステータスコードなど）も対象とする。

ODSシステム内部の稼働情報（処理ログ）:

  • システム全体の状態および各処理結果を対象とする。

  • 対象とするシステムの要件や形態によって具体的な情報は様々であるため、システムごとの可用性や運用性を考慮して選別する。

  • 各情報は集約して監視可能な形式で記録する。

ODSと連携する連携サービスの情報（サービスログ）:

  • 連携サービスごとの各種機能や処理結果に関連する情報を記録対象とする。

  • サービスによっては機密性の高い情報を含むため、適切な保護が求められる。

hashtag
Normative Requirements（規定要件）

hashtag
共通

  • shall: 各種ログは標準的なフォーマット（例: JSON, XML, CSV）で記録されなければならない。

  • shall: 各種ログはその元となる事象に関する時系列情報を含まなければならない。

  • should: 各種ログに含まれる機密性の高い情報については、記録時に匿名化などサービスの要件に応じた処理を実施することを原則とする。

  • should: 各種ログのうち信頼性がサービス品質に直結するログについては改ざん防止のための処理を実施することを原則とする。改ざん防止のアプローチの例としては検知（ハッシュや署名など）や、永続化（イミュータブルストレージやWORM（Write Once Read Many）メディア）などが挙げられる。

  • should: ログの保存期間はシステムの要件に基づき決定することを原則とする。この期間は監査や証跡のような制約による場合もある。

  • may: 各種ログは一貫性をもってアクセスする手段が提供されることを前提に、中央集約型、分散型いずれのストレージやデータベースでも利用してもよい。

  • may: 各種ログはログ永続化の容量の肥大化を防ぐため、過去のログを削除するログローテーション機能を実装してもよい。

hashtag
通信ログ

  • should: 通信ログの記録内容には、以下の主要メタデータを含むことを原則とする。

    • タイムスタンプ

    • クライアントのIPアドレス

    • リクエストアドレス

    • アクセスメソッド（例: HTTP GET, POST など）

    • ステータスコード（例: HTTP 200 OK など）

    • リクエスト/レスポンスヘッダー（機密情報を除く）

    • 通信ログの追跡のための識別子（X-TrackingID など）

hashtag
処理ログ

  • should: 処理ログの記録内容には以下を含めることを原則とする。

    • リソース利用状況（CPU、メモリ、ディスク容量 など）

    • 発生したエラーの種別及び内容

  • should: 処理ログを外部サービスと連携する仕組みを提供することを原則とする。

hashtag
サービスログ

  • should: サービスログの記録内容には以下を含めることを原則とする。

    • 各サービスの処理結果（成功/失敗）

    • 各サービスのトレースのためのサービス識別子

最終更新