ベスト・プラクティス

Oracle Log Analyticsの構成のベスト・プラクティス

• ログ・グループの計画:

  Oracle Log Analyticsでは、ログ・グループは、収集されたログを編成および格納するための論理コンテナとして機能します。各ログ・グループは特定のコンパートメント内に存在するため、ユーザー・アクセス制御が容易になります。コンパートメント・レベルで適切な権限を割り当てることで、そのコンパートメントのログ・グループに含まれるログへのアクセス権を持つユーザーを管理できます。

  ログを格納するログ・グループの作成およびログ・グループの管理を参照してください。

  ログ・グループを慎重に計画することで、次のことが保証されます。

  • 効率的なアクセス制御: 適切なユーザーおよびグループ・アクセスを特定のログ・データに割り当てます。
  • スケーラビリティ: 組織の成長に合わせて構造を簡単に適応できます。
  • コンプライアンスとセキュリティ: 機密ログを適切に分離することで、規制上のニーズをサポートします。
  • メンテナンスの容易性: 問合せ、アラートおよびトラブルシューティングを簡素化します。

  ログ・グループの編成方法: 次の一般的な方針を検討してください。

  • ログ・タイプ別: ログをタイプ別にグループ化します(アクセス・ログ、監査ログ、セキュリティ・ログ、アプリケーション・ログなど)。
  • エンティティまたは環境別: ログをサーバー、アプリケーション、ビジネス・ユニットまたは環境(本番、開発、テストなど)別に編成します。
  • 顧客別(サービス・プロバイダ用): 分離とカスタマイズされたアクセス制御を保証するために、顧客ごとに個別のログ・グループを作成します。

  シナリオの例:

  • 例1: サービス・プロバイダには、基本的な運用ログを格納するOperationsと、機密情報が含まれるためにアクセス制限が必要なログを含むSecured Contentという2つのコンパートメントがあります。各コンパートメントには、多数のログ・グループを含めることができます。たとえば、Operationsコンパートメントには、サーバー・ログとアクセス・ログがあります。セキュア・コンテンツ・コンパートメントには、監査ログおよびトランザクション・ログが含まれます。OCI IAMポリシーを使用して、Operatorsユーザー・グループにOperationsコンパートメントへのアクセス権が付与され、Auditorsユーザー・グループにSecured Contentコンパートメントへのアクセス権が付与されます。各ユーザー・グループは、アクセス権を持つコンパートメントのログのみを表示できます。

  • 例2: セキュリティ・ソフトウェア会社には、特定のビジネス・ニーズに対応するログ・グループを含む4つのコンパートメント(WebAccess、DBA、認証およびエンドポイント)があります。アクセス制御は、組織ロールに合せてコンパートメント・レベルで管理されます。

  計画に関する質問: ログ・グループを作成する前に、次のことを考慮してください。

  • どのタイプのログが収集されますか。
  • 各ログ・グループにアクセスする必要があるのはどのチームまたはユーザーですか。
  • 特定のログを分離するための規制やビジネスの推進要因はありますか。
  • 組織は将来、ログ・ストレージを拡張または再編成する必要がありますか。

  推奨されるベスト・プラクティス:

  • エンゲージ・ステークホルダー: ログ・グループ構造を計画するときに、運用、セキュリティおよびコンプライアンス・チームを関与させます。
  • IAMポリシーとの連携: ログ・グループおよびコンパートメント構造がOCI IAMポリシーと一致していることを確認して、アクセス制御を合理化します。
  • 過剰なグループ化の回避: セキュリティとメンテナンスが複雑になる可能性があるため、すべてのログをまとめてグループ化しないでください。
  • ドキュメントとレビュー: ログ・グループの戦略をドキュメント化し、組織のニーズを満たし続けるように定期的にレビューします。

  ヒント: ログ・グループ組織を計画する時間を事前に投資することで、ログ管理とセキュリティが合理化され、長期的なメンテナンス・オーバーヘッドが削減されます。

• 効率にラベルを使用:

  ラベルは、ログ・エントリに追加できる追加のテキストです。追加のテキストは、Authentication Failure、User Logged In、Application Shutdownなど、ログに共通する署名のタイプを示すラベルの事前定義済ライブラリから取得できます。これらの文字列は、複数値のLabelフィールドに追加されます。

  ラベルは、ログ・エントリ内の任意のフィールドに任意の値を追加することもできます。たとえば、ログ・エントリに404のような数値ステータス・コードが含まれている場合、Not Authorizedなどのテキスト文字列をフィールドStatus Messageに追加できます。

  ラベル定義に移入されたラベル・フィールドまたは出力フィールドは、他のフィールドと同様に問合せで使用できます。

  ラベルはログ・ソースで定義され、ログ・データが取り込まれると評価されます。ラベル定義は、ラベル定義がログ・ソースに追加された後に取り込まれた新しいログ・データにのみ適用されます。収集された履歴ログ・データは、新しく追加されたラベル定義でエンリッチされません。

  取込み時にログをエンリッチすることで、次のことができます。

  • 複雑な評価がすでに行われているため、問合せの速度が向上します。
  • 問合せを簡略化して、読みやすくします。

  ログ・エクスプローラで記述された次の問合せの例を考えてみます。

   'Log Source' = 'FMW WLS Server Access Logs' and
   (URI like '%/services/loans/accountcreateservice%'
     or URI like '%/services/agreements/history%'
     or URI like '%/services/transferservice%'
     or URI like '%/services/update/adjustmentservice%' )

  この問合せは、4つの文字列に対してワイルドカード検索を実行しているため、非常にコストがかかる場合があります。長期間にわたって実行すると、タイムアウトする可能性があります。また、ダッシュボードやアラートなどで問合せが頻繁に繰り返される場合、多くの処理リソースが取得される可能性があります。

  別の方法として、次のようにFMW WLSサーバー・アクセス・ログ・ソースに4つのラベル条件を作成する方法があります。

  If URI contains ''services/loans/accountcreateservice' set service=loanaccountcreate
  If URI contains ''/services/agreements/history' set service=agreementhistory
  If URI contains ''/services/transferservice' set service=transferservice
  If URI contains ''/services/update/adjustmentservice' set service=adjustmentservice
  

  その場合、問合せは次のようにリライトできます。

  'Log Source' = 'FMW WLS Server Access Logs' and
  Service in (loanaccountcreate, agreementhistory, transferservice, adjustmentservice)

  これは読みやすく理解しやすく、問合せの実行も大幅に向上します。

  URIに前述の4つのパターンのいずれかが含まれ、Watched-URIのようなラベルを追加する場合、単一のラベル定義を作成することもできます。この場合、問合せは次のようになります。

  'Log Source' = 'FMW WLS Server Access Logs' and
  labels = Watched-URI

  検出ルールを作成して、取込み時に特定の条件で受信ログを検出することもできます。Create a Label、Use Labels in Sources、Detect Predefined Events at Ingest Time、Oracle-defined Detection Labels、およびFilter Logs by Labelsを参照してください。

ロギングのベスト・プラクティス

次に、アプリケーションおよびシステムを構成する方法、またはログを生成するソフトウェアを作成する方法のベスト・プラクティスを示します:

• タイムスタンプをUTCで記録: これは、夏時間(DST)の切替えによるギャップの回避に役立ちます。ログ・エクスプローラでログを表示するときに、タイムスタンプをローカル時間に変換できます。