SDPFを使ってみた　第3回　～SDPFサービス群の組合せ事例のご紹介＜FRAでのログ保存ユースケース＞～

はじめに

こんにちは。プラットフォームサービス本部データプラットフォームサービス部でSmart Data Platform(SDPF)のサービス企画を行っている安井・小野です。閲覧頂きありがとうございます。我々は当社が提供しているSDPFサービスを組合わせた具体的な事例紹介をしています。

前回の第2回では、1点目としてオンライン化が広がる中でのバックアップの重要性(Micosoft365の安全なバックアップ)について、例えばSDPFサービスを使った場合にはどのように実現できるのかについてご紹介しました。

2点目として現在社会問題になっているランサムウェア対策については、データ保存の観点で改ざん防止に対応したWasabiのオブジェクトロック機能を使用することで、万一不幸にしてランサムウェア被害にあった際にも、安全なデータからシステムやシステムデータを復旧する方法について説明しました。

このように誰もが気軽にオンライン化されたサービスを容易に利用できる反面、外部から時間を問わずいつでもあらゆる側面からアクセスされるかもしれないという状態にもあり、「自分達の資産は自分達で守る」取組みが一層求められています。

自社の情報資産を明確化し、適切な権限設定がされており、許可されたものだけが使用可能な状態を保つ。
それらを使用した形跡を記録化し、定期的に確認する。かつ各種のアクセス情報はログ情報として一定期間、保存する。
万一の問題発生時には、ログ情報を元に分析し、原因の追究、対策を実施する。

背景

オンライン化/リモート化に伴い、オフィス外からのリモートアクセスの利用が進む

時間と場所に制約を受けない働き方が進んできており、そのニーズの高まりから、SDPFネットワークサービスメニューの1つであるFlexible Remote Accessの利用が進んでいます。 Flexible Remote Access (FRA)とは外出先や自宅等あらゆる場所からセキュアにアクセスできるリモートアクセス＆セキュリティ基盤です。

ログを取っていなかったら何も分からない!?

「適切な権限設定」に基づき「許可されたユーザー」がアクセスし「どのようなアクセスを行ったのか」、「不正な通信をした形跡はないのか、または恐れがないのか」等、総合的なセキュリティ対策を実施して運用する必要があります。その中でも「通信アクセスに関するログ情報」は重要なデータであり、リアルタイム分析をして対応する形態や、万一の問題発生時に過去のログを参照して分析したり、活動証跡といった監査目的のためにログを保存しておく形態等があります。

SDPFサービスを利用してどのように実現したか

以下NTT Comのサービスを組み合わせて、FRAを使用して発生するログ情報を、クラウド上に長期間保存できる方法を実現しました。

閉域網から各種クラウドサービスに接続するインターコネクトサービス「Flexible InterConnect (FIC)」を使ったセキュアな通信経路の確立。
安価なストレージサービス「Wasabiオブジェクトストレージ(Wasabi)」の利用。
SDPFクラウド/サーバーのサーバーインスタンスを利用。

検証を通じた確認

実際に検証環境を作ってみた

今回は図のような検証環境を構築しました。特徴は以下となります。

FICを活用することにより、 FRAはもちろんのこと、WasabiやSDPFクラウド/サーバー等様々なサービスと閉域で接続可能な状態にしました。
ログ受信サーバーはSDPFクラウド/サーバーのサーバーインスタンス上に導入しました。

f:id:NTTCom:20220323165448p:plain

実際に検証を実施してみた

FRAから発生するトラフィックログや脅威ログ、URLフィルタリングログといった各種ログをFIC経由でSDPFクラウド/サーバー上のログ受信サーバーに転送し、別途作成したシェルスクリプトを用いることにより、日ごとにまとめたzipファイルを同サーバーのローカルディスクやWasabiに長期保存する検証をしました。

確認後の具体的な気付きポイント

FRAには0系と1系の環境があり、それぞれのポータル上にて手動で設定する必要がありました。

ログ受信サーバーにはOSSであるFluentdを用いました。 Fluentdでは、Fluentd内の"タグ"に設定したキーワードを元にログを処理することが出来ます。また、FRAでは送信するログのファシリティをそれぞれのsyslogサーバープロファイルごとに設定出来ます。

これらの機能を組み合わせることにより、例えばトラフィックログであれば「LOG_LOCAL0」を、脅威ログであれば「LOG_LOCAL1」をFRA側で設定します。そして、Fluentd側では、0系および1系のホスト情報をタグに設定することにより、"タグ.ファシリティ"別にログの保存先ファイルを分けることが出来ました。

f:id:NTTCom:20220323165455p:plain

下記はFluentdの設定ファイルです。トラフィックログと脅威ログに関する設定のみ抜粋していますが、他のログも同様となります。

/etc/td-agent/td-agent.conf

######################################
# FRAからのsyslog受信                #
######################################
<source>
  @type syslog
  port 514
  bind 0.0.0.0
  tag FRA
  <transport tcp>
  </transport>
  <parse>
    message_format auto
    with_priority true
  </parse>
</source>
######################################
# 受信ログをサーバー別にタグで分類    #
######################################
<match FRA.**>
  @type rewrite_tag_filter
# 0系用タグ
  <rule>
    key      host
    pattern  0系のホスト名
    tag      "0系のホスト名.${tag}"
  </rule>
# 1系用タグ
  <rule>
    key      host
    pattern  1系のホスト名
    tag      "1系のホスト名.${tag}"
  </rule>
</match>

########################################################
# サーバー+ファシリティ別にログファイルへログを書き込み  #
########################################################
# 0系
# トラフィックログ
<match 0系のホスト名.FRA.local0.**>
  @type file
  path /var/log/FRA/FRA.0系のホスト名.traffic.*.log
  append true
  <buffer>
    timekey       1d       # 1day
    timekey_wait 10m       # 10mins deley for flush
    timekey_use_utc false  # local
  </buffer>
</match>

# 脅威ログ
<match 0系のホスト名.FRA.local1.**>
  @type file
  path /var/log/FRA/FRA.0系のホスト名.threat.*.log
  append true
  <buffer>
    timekey       1d       # 1day
    timekey_wait 10m       # 10mins deley for flush
    timekey_use_utc false  # local
  </buffer>
</match>

~ 途中割愛 ~

# 1系
# トラフィックログ
<match 1系のホスト名.FRA.local0.**>
  @type file
  path /var/log/FRA/FRA.1系のホスト名.traffic.*.log
  append true
  <buffer>
    timekey       1d       # 1day
    timekey_wait 10m       # 10mins deley for flush
    timekey_use_utc false  # local
  </buffer>
</match>

# 脅威ログ
<match 1系のホスト名.FRA.local1.**>
  @type file
  path /var/log/FRA/FRA.1系のホスト名.threat.*.log
  append true
  <buffer>
    timekey       1d       # 1day
    timekey_wait 10m       # 10mins deley for flush
    timekey_use_utc false  # local
  </buffer>
</match>

~ 以降割愛 ~

f:id:NTTCom:20220323165501p:plain