Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Upcoming SlideShare
What to Upload to SlideShare
Next
Download to read offline and view in fullscreen.

11

Share

Download to read offline

【JEUG】 オープンSIEMの世界へ

Download to read offline

日本Elasticユーザグループ

Related Books

Free with a 30 day trial from Scribd

See all

【JEUG】 オープンSIEMの世界へ

  1. 1. 1 2018/6/19(Tue) Future Architect, Inc. Hisashi Hibino オープンSIEMの世界へ (ElasticStackと共に歩み続けたセキュリティログ分析)
  2. 2. 2 自己紹介 名前:日比野 恒 (ひびの ひさし) 所属:フューチャーアーキテクト株式会社 セキュリティアーキテクト (CISSP、CISA、情報処理安全確保支援士)  AIなどの「システム高度化」により、ITリテラシーの非対称性が拡大している  IoT/コネクテッド領域など、ITが人々の生活に密接に関わるにつれ、危機感を持つようになる  オープンな技術を用いたセキュリティログの分析プラットフォーム開発に目覚め、今に至る
  3. 3. 3 ログ分析システム Elasticとの出会いは意外なところから... 3年前に構築した金融機関のマイナンバー管理のサブシステムでいきなり本採用!! データベース (暗号化) WebAPIPSLBFW LAN Internet 利用ユーザ (スマホ) 番号登録担当 (PC端末) 踏台 SQL監査ログAPI実行ログ 認証ログ 通信ログ LogstashElasticsearchKibana 【法令要件に準拠するため、業務視点での監視と監査を実現】 ①マイナンバーを参照するAPIはが叩かれたら不正操作とする。 ②申請外で踏台ログインや直接データベース接続されたら不正操作とする。 操作録画ソフト マイナンバー SQLAPI
  4. 4. 4 1. オープンSIEM構想
  5. 5. 5 ログ管理製品の分類 Syslog 統合ログ管理 SIEM 相関分析 正規化 可視化 ログアーカイブ(長期保管)用途 ログ分析(リアルタイム)用途 ※IO性能よりもディスク容量やセキュリティ重視 ※ディスク容量よりもIO性能重視 【製品例】 ①Qradar ②McAfeeSIEM ③Splunk Enterprise 【製品例】 ①LogStorage ②LogRevi ③EventLog Analyzer 【製品例】 ①Kiwi Syslog ②rsyslog ③syslog-ng ログ収集 相関分析 正規化 可視化 ログ収集 相関分析 正規化 可視化 ログ収集 SIEM(Security Information and Event Management)は、セキュリティ脅威検知に特化したログ管理製品。
  6. 6. 6 オープンSIEM構想とは 「オープンな技術」、「オープンな環境」でSIEMを作りたい! × 例えば、各製品のログフォーマットを正規化するためのLogstashのフィルタを公開。 少ない貴重なエンジニアリソースをシェアリングして皆でオープンな技術でSIEM開発していく。 オープンな技術 オープンな環境
  7. 7. 7 保護対象システム ネットワーク (多層防御) オープンSIEMカバー範囲 業務視点でのセキュリティ監視に強みを発揮 業務とアプリケーションに強みを持つ者の視点でセキュリティ監視を実現する。 フ ァ イ ア ウ ォ ー ル IDS/IPS WAF ア ン チ ウ ィ ル ス サ ン ド ボ ッ ク ス ス パ ム フ ィ ル タ 外部脅威 内部不正 インスタンス/サーバ OS データ(機密) データベース アプリ ミドル クラウドサービス (AWS、Azure、GCP...etc) 一般的な商用SIEM製品の得意領域 我々のSIEMの得意領域 外部からシステムを守ることを主目的としているため 入り口になるネットワーク寄りの監視が得意領域 業務視点で見張ることに より内部不正を検知する
  8. 8. 8 シンプルな分析画面とすること! 絞り込み用に表形式グラフと発生タイミングが分かるよう積立棒グラフがあれば十分という結論。 秘密 秘密 秘密 秘密 秘密 絞 り 込 む 分 析 軸
  9. 9. 9 2. セキュリティは経営課題に
  10. 10. 10 サイバーセキュリティは経営課題です! 2015年12月に経済産業省から経営者向けのガイドラインが公開され、すでにVer2.0。 【参考】 http://www.meti.go.jp/policy/netsecurity/mng_guide.html
  11. 11. 11 70%の企業が攻撃に気づいていない 2015年の日本年金機構の事件を境に報告数急増。約70%が外部からの指摘で発覚。 2013年 2014年 2015年 2016年 0 出典: 「平成28年におけるサイバー空間をめぐる脅威の情勢について」(警視庁) 492 1,723 4,046 1,000 2,000 3,000 4,000 3,828
  12. 12. 12 超スピードで巧妙になっていくサイバー攻撃 この1年間で実際にお客様環境において観測されたサイバー攻撃の事例。 1.マイニングマルウェア攻撃 →Weblogicの脆弱性を突く攻撃 2.ランサムDDoS攻撃 →ビットコイン支払いを求めるDDoS
  13. 13. 13 【参考】こういう事件に巻き込まれないように!! 他人のマシンリソースでのマイニングはウィルス罪です。加害者にならないように気をつけて! 【参考】https://doocts.com/3403
  14. 14. 14 WAF サイバーリスク対策、どこまで出来ていますか?? システム導入後のパッチ適用は困難、脆弱性の定量的な管理も困難! 不正なWeb通信 (既知の攻撃) Webサーバ 攻撃者 本質的な対応 パッチ適用後は 攻撃は失敗する パ ッ チ 適 用 が 困 難 な 場 合 WAFによる対応 不正なWeb通信 (既知の攻撃) Webサーバ 攻撃者 不正な通信を検 知、遮断する Webアプリケーション 脆弱性は残ったまま WAF WAF/ に よ る 防 御 が 困 難 な 場 合 それでも残る課題 不正なWeb通信 (ゼロデイ攻撃) Webサーバ 攻撃者 攻撃コードが公開 されないとシグネ チャは作れない Webアプリケーション 脆弱性は残ったまま
  15. 15. 15 インストール済ソフトウェア情報(エージェントレス) 当社セキュリティコンサルではこんなことをしてたりも... 当社開発のOSS脆弱性スキャナVulsとオープンSIEMとの組み合わせによる脆弱性監視。 Webサーバ アプリサーバ DBサーバ 基幹システム Internet ハッカー(攻撃者) レッドチーム(当社) 脆弱性情報 Vulnerability DB マッチング Vulsを活用することでパッチ適用出来ない環境において ケアの必要な脆弱性をCVE単位で定量化して管理可能 セキュリティ運用者 オープンSIEM ログ収集 Vulsで把握出来ている脆弱性に対する 攻撃コードをアクセスログ等から検知する
  16. 16. 16 3. Elastic Stackの紹介
  17. 17. 17 Elasticを活用したSIEMプラットフォームサービス 脅威分析のユースケースにおいて、Elasticプロダクトを活用するとこんな感じになる。 Kibana Elasticsearch Logstash Beats Alerting Monitoring Graph Security X-Pack Elastic Stack (オープンソース) 有償サブスクリプション Machine Learning Reporting 正規化 保存/蓄積 可視化 認証/暗号化 通知 相関分析 異常検知取り込み Platinum Edition Gold Edition ※ 有償サブスクリプションを購入することでX-Packの有償機能とElasticのサポートを受けられる。 ※ エディションに応じて、利用できる機能およびサポートレベルが異なる。 ※ ライセンスは本番環境のElasticsearchクラスタ内のノード数分を購入する。(クォーラム維持に必要な最小3ノードから) 本 日 は 私 の 好 き な こ の 辺 り を
  18. 18. 18 有償プラグイン(X-Pack) 有償プラグインであるX-Packでは、エンタープライズ向けに6種類の製品が提供されている。 Security Monitoring Reporting Alerting Graph Machine Learning  データの変化を検知  多種多様な通知方法  ダッシュボードのレポート化(PDF等)  Alertingと組み合わせたレポートのスケジュール通知  Elasticsearchクラスタの性能情報  Kibanaの性能情報  Logstashの性能情報  データの関連性を可視化  教師無し機械学習によるデータ分析  時系列異常検知  はぐれ者検知  稀有な非構造メッセージ検知  Kibanaの認証  Kibanaの通信暗号化  AD/LDAP認証連携  API監査  ドキュメント暗号化
  19. 19. 19 LogstashとBeatsの使い分け Elasticには、データの取り込みツールに「Logstash」と「Beats」の2種類がある。 正しい使い分けについて質問を頂くことが多いため、まとめてみた。  Go言語による実装でシンプルで軽量  特定ソースからのデータ取り込み  データ保存先は1つのみ  エージェント用途での利用  Javaベースで大量メモリ消費  多種多様なソースからのデータ取り込み  多種多様なフィルタによるデータ加工  多種多様な保存先にデータ出力 対象システムに負荷を掛けず用途に応じて 効率よくデータを取得することに特化 ETLツールとして、分析に活用したい データをほしい形に加工することに特化
  20. 20. 20 【参考】フロー情報もSankeyダイアグラムを使えば シンプルな画面をオススメしておきながら、Vegaで遊ぶことも忘れてないよ!! 【参考】 https://www.elastic.co/blog/custom-vega-visualizations-in-kibana 通 信 フ ロ ー 可 視 化 か ら 読 み 取 れ る 情 報 は 多 い
  21. 21. 21 4. Logstashの話
  22. 22. 22 フォーマットの異なる複数ログを取りこむ際のポイント オンプレ環境で複数ログをSyslogで取り組む場合はLogstashの前にsyslogサーバを挟む。 logstash rsyslog等 ログ形式① (Firewall) ログ形式② (WAF) input file input file grok -> geoip -> date -> mutate csv -> geoip -> date -> mutate output elasticsearch output elasticsearch Elasticsearch Index① Index② Index③ ログ形式③ (IPS) input file grok -> geoip -> date -> mutate output elasticsearch Firewall WAF IPS 【設計ポイント①】 異なるログ形式を同じinput syslogで取得して、異なる正規化フィルタに 掛けることが出来ないため、rsyslogで受信して別ファイルにしてすることで input fileで異なるフィルタで正規化することが可能となる。 【設計ポイント②】 multi pipeline機能を利用してログ形式ごとにconfファイルを作成することでフィルタを シンプルにすることが可能であり、リソース管理もpipeline単位で制御出来るメリットがある。 【設計ポイント③】 格納するログ形式が異なるため、ElasticsearchのIndexも ログごとに分けることで性能面や運用面でメリットがある。 kibana
  23. 23. 23 【参考】AWS環境の場合、ログは全てS3を介して取り込むべし ログ形式毎にフォルダを切ってS3にログを収集することで障害時のハンドリングが容易になる。 ログファイル データベース ネットワーク機器 イベントログ Filebeat Winlogbeat Logstash (収集) input jdbc input tcp/udp (syslog/netflow) S3 Bucket (bucket-a) /log /backup AWS各種アクセスログ Logstash (正規化) S3アクセスログ CloudFront アクセスログ ELB アクセスログ Elasticsearch input s3output s3 output es 1 2 3 input { s3 { backup_to_bucket => “bucket-a" backup_add_prefix => “backup/" delete => "true" bucket => "bucket-a" region => "ap-northeast-1" prefix => “log/log-a" interval => "5" sincedb_path => "/var/lib/logstash/sincedb" } } log-a Logstashで取り込まれた後 生ログは/backupで保持される
  24. 24. 24 RDSのSQL監査ログ(1/3) S3経由で取得したRDS(Oracleエンジン)のSQL監査ログのinput区はこんな感じ。 input { s3 { id => "rds-audit" bucket => “SIEM-AUDIT" prefix => "/rds/audit/" region => "ap-northeast-1" sincedb_path => "/var/lib/logstash/sincedb_rds-audit" codec => multiline { pattern => "(<?xml .*|<Audit .*|xmlns:xsi|xsi:schemaLocation|<Version>|</AuditRecord>|</Audit>)" negate => true what => "next" } } } RDS Oracleのaudit_trailをOS形式で出力すると1レコードが複数行にまたがるログとなるため、codecでmultilineを指定する。 Patternで指定した文字列以外(negateがtrue)の行は、最初の行の後ろ(whatがnext)に追記して1件のログと認識する。 【参考】 https://dev.classmethod.jp/cloud/aws/rds-oracle-copy-audit-logs-to-s3/
  25. 25. 25 RDSのSQL監査ログ(2/3) filter区はこんな感じ。次ページに続くw filter { xml { source => "message" store_xml => false xpath => [ "/AuditRecord/Audit_Type/text()","Audit_Type", "/AuditRecord/Session_Id/text()","Session_Id", "/AuditRecord/StatementId/text()","StatementId", "/AuditRecord/EntryId/text()","EntryId", "/AuditRecord/Extended_Timestamp/text()","Extended_Timestamp", "/AuditRecord/DB_User/text()","DB_User", "/AuditRecord/OS_User/text()","OS_User", "/AuditRecord/Userhost/text()","Userhost", "/AuditRecord/OS_Process/text()","OS_Process", "/AuditRecord/Terminal/text()","Terminal", "/AuditRecord/Instance_Number/text()","Instance_Number", "/AuditRecord/Object_Schema/text()","Object_Schema", "/AuditRecord/Object_Name/text()","Object_Name", "/AuditRecord/Action/text()","Action", "/AuditRecord/TransactionId/text()","TransactionId", "/AuditRecord/Returncode/text()","Returncode", "/AuditRecord/Scn/text()","Scn", "/AuditRecord/Comment_Text/text()","Comment_Text", "/AuditRecord/Sql_Bind/text()","Sql_Bind", "/AuditRecord/Sql_Text/text()","Sql_Text", "/AuditRecord/OSPrivilege/text()","OSPrivilege", "/AuditRecord/DBID/text()","DBID" ] } xml形式のログフォーマットであるため、xml filterを利用する。 message内容をxpath指定でfieldとvalueに分解する。
  26. 26. 26 RDSのSQL監査ログ(3/3) S3へのRDS OracleのSQL監査ログのアップデート方法にてログの重複の可能性があるため... if [DB_User][0] == "/" { drop {} } fingerprint { source => "message" target => "[@metadata][fingerprint]" method => "MURMUR3" } date { match => [ "Extended_Timestamp[0]" , "yyyy-MM-dd'T'HH:mm:ss.SSSSSS'Z'" ] timezone => "UTC" target => "@timestamp" } mutate { add_field => { "file" => "%{[@metadata][s3][key]}" } } } output { elasticsearch { hosts => [ “<ElasticsearchのURL>:9200" ] index => "rds-audit-%{+YYYYMMdd}" document_id => "%{[@metadata][fingerprint]}" } } ハッシュ値が一意になるようにsourceとしてmessageを指定する王道。 ※同じmessageとなるログは基本的には存在しないため method(利用するアルゴリズム)には、衝突率と処理速度でMURMUR3。 document_idにfingerprintのtargetで指定したメタフィールドを利用。 ※障害時のログ取り込みの重複を防ぐ効果あり
  27. 27. 27 CloudTrailの操作ログ CloudTrailの操作ログはCloudwatchLogsに寄せるとJSON形式でキレイに取れる。 【参考】 https://github.com/lukewaite/logstash-input-cloudwatch-logs input { cloudwatch_logs { region => "ap-northeast-1" log_group => [ "CloudTrail/AWSLogGroup" ] sincedb_path => "/var/lib/logstash/sincedb_cloudtrail" codec => json } } filter { json { source => "message" } date { match => [ "eventTime", "ISO8601" ] timezone => "Asia/Tokyo" locale => "en" target => "@timestamp" } geoip { source => "sourceIPAddress" } } Githubからコミュニティプラグインの logstash-input-cloudwatch-logsを導入する ことで複数並列の[]を正規化してくれる。 複雑すぎてgrok filterではほぼ不可能(´;ω;`)
  28. 28. 28 【参考】CloudTrailのログの分析ポイント 管理コンソールへのログインやAPI操作を「いつ」・「誰が」・「どこから」実行したかを抑える。 ※Logstashのgeoip filterを用いて、送信元IPアドレスに国情報を付加しておく。 eventType AwsAPICall AwsConsoleSignIn userIdentity.type responseElements.ConsoleLogin IAMUser Root AWSService AssumedRole AwsAccount eventName Console Login CheckMfa SwitchRole Success Failure responseElements.CheckMfa Success Failure responseElements.SwitchRole Success Failure Field Name Value 【凡例】 Additional EventData.MFAUsed Yes No geoip.ip geoip.country_name userIdentity.type userIdentity.username @timestamp eventName API名 API名 ※ APIごとにイベントが存在し、大量のイベントが存在する。 存在しないIAMUserでログイン施行があると 「userIdentity.username 」に 「HIDDEN_DUE_TO_SECURITY_REASONS」と出る。 MFAを利用したログイン行為を実施しているかのチェックに 「Additional EventData.MFAUsed」を利用する。
  29. 29. 29 DDoS攻撃やSQLインジェクション攻撃には... ログデータを利用したい形式に加工することで迅速なインシデントレスポンス対応が可能に!! Webアクセスログ file grok geoip dns Elastic search 【辛みポイント①】 CSVフィルタでトライするもURLにSQL インジェクションで使われる文字列が入り separatorが機能せず Σ(・□・;) 結果的にgrokフィルタで落ち着く。 【辛みポイント②】 キャッシュ有効化するもそんなにヒットしない ため、都度DNSサーバに問い合わせに... 性能が5分の1くらいまで下がる。
  30. 30. 30 これだけ嬉しいことが起きるはず (^^) 1. SyslogサーバからFirewallログ取得 2. 国情報から国外アクセスを検索 3. 国外IP一覧をIPアドレスごとに集計 4. IPアドレスをWhoisでホスト名検索 5. 不審なIPアドレスをFirewallでブロック 繰り返す 1. SyslogサーバからFirewallログ取得 2. 国情報から国外アクセスを検索 3. 国外IP一覧をIPアドレスごとに集計 4. IPアドレスをWhoisでホスト名検索 5. 不審なIPアドレスをFirewallでブロック ElasticStack に よ る 自 動 化
  31. 31. 31 【参考】ログ分析に関するおすすめブログ 2018年5月22日公開のブログで、ログ分析に必要な内容がまとまっている!! 【参考】 https://www.elastic.co/blog/a-practical-introduction-to-logstash
  32. 32. 32 【参考】私がログ分析でよく使うフィルタたち # フィルタ名 説明 1 grok 非構造データを正規表現を用いて構造化データに変換するフィルタ 2 date ログ内の日付データを@timestampに置換するフィルタ 3 mutate fieldの型を変更したり、fieldを追加削除、編集するフィルタ 4 geoip ログ内のIPアドレスに国情報や緯度経度情報を付加するフィルタ 5 dns IPアドレスからホスト名(逆引き)、またはその逆の正引きを行うフィルタ 6 drop 条件に合致するログレコードを廃棄させるフィルタ 7 csv csv形式のログデータをfieldとvalueに分割するフィルタ 8 kv key=value形式のログデータをfieldとvalueに分割するフィルタ 9 xml xml形式のログデータをfieldとvalueに分割するフィルタ 10 translate valueの中身を指定した文字列に合致したら置換させるフィルタ 11 fingerprint 指定したfieldのvalueからハッシュ値を生成し、新たにfield化するフィルタ
  33. 33. 33 5. Beatsの話
  34. 34. 34 Windowsイベントログの監視
  35. 35. 35 イベントログの内容理解に努めるべし! どのイベントログを取得すると実現したい監視が出来るのか、しっかりと検証して抑えること。 【よく参考にしているサイト】 Windowsで出力されるセキュリティイベントの一覧情報について https://blogs.technet.microsoft.com/jpntsblog/2017/02/27/security-event/ Windowsイベントログ システム、アプリケーションのエラーログ http://eventlog.whitefox.jp/?eid=1 ログを活用したActive Directoryに対する攻撃の検知と対策 https://www.jpcert.or.jp/research/AD.html
  36. 36. 36 イベントログ取得はもちろんWinlogbeatにお任せ! イベントログの取得は、WinlogbeatでイベントIDを取得するだけでOK! # イベントID 内容 1 21 OSログイン成功 2 23 OSログオフ成功 3 24 OSセッション切断 4 25 OSセッション再接続 5 4625 OSログイン失敗 【winlogbeat.yml】 winlogbeat.event_logs: - name: Microsoft-Windows-TerminalServices-LocalSessionManager/Operational tags: ["login"] event_id: 21,23,24,25 - name: Security tags: ["login"] event_id: 4625 Securityの「成功の監査」や「失敗の監査」の イベントを取るよりもこのログを取るほうが正確な OS認証ログが効率よく取得できる。(オススメ) 踏台サーバの利用終了時 ちゃんとログオフしていない アカウントの監視ができる。 (セキュリティポリシー違反の監査) 【認証関連イベント情報】
  37. 37. 37 Windowsのログイン監査グラフ Y軸を件数、X軸を時系列(日単位)でログインアカウント毎に積立棒グラフで表示する。 「いつ」、「誰が」、「何回」、ログイン成功もしくは失敗したのか監査が可能。 User A User B User C 【サンプル:ログイン成功グラフ (イベントID:21)】
  38. 38. 38 【参考】ファイル操作に関するイベントログと表示される項目一覧 項目名 / イベントID 4656 (OPEN) 4656 (DELETE) 4658 (CLOSE) 4663 (ACCESS) 4690 (COPY) AccessList ● ● - ● - AccessMask (CRUDの情報) ● ● - ● - AccessReason ● ● - - - HandleId ● ● ● ● - ObjectName (フォルダ名やファイル名のフルパス) ● ● - ● - ObjectServer ● ● ● ● - ObjectType (DirectoryまたはFile) ● ● - ● - PrivilegeList ● ● - - - ProcessId ● ● ● ● - ProcessName ● ● ● ● - ResourceAttributes ● ● - ● - RestrictedSidCount ● ● - - - SourceHandleId - - - - ● SourceProcessId - - - - ● SubjectDomainName (ユーザのドメイン名) ● ● ● ● ● SubjectLogonId ● ● ● ● ● SubjectUserName (アカウント名) ● ● ● ● ● SubjectUserSid ● ● ● ● ● TargetHandleId - - - - ● TargetProcessId - - - - ● TransactionId ● ● - - - COPYしたファイル名をイベンID:4690 単体でトレースすることは出来ない。
  39. 39. 39 【参考】JPCERT/CCの情報も参考に!! 内部不正を見張る上で地味に活用できるイベントIDを紹介 出典:ログを活用したActive Directoryに対する攻撃の検知と対策(JPCERT/CC) # イベント名 イベントID 内容 1 Security 1102 イベントログの削除 2 Security 4672 特権の割り当て 3 Security 4698 スケジュールされたタスクの作成 4 Security 4768 Kerberos認証(TGT要求) 5 Security 4769 Kerberos認証(ST要求)
  40. 40. 40 LinuxのOS認証ログの監視
  41. 41. 41 LinuxのOS認証ログは、やっぱりこれですね! OS認証ログ、コマンド実行ログ、ファイル操作ログ、ファイル改ざん検知ログ等を取得可能。
  42. 42. 42 ルールの書き方はaudit.rulesと同じ auditdのプロセスを停止して、auditbeatでログ取得する方が正規化不要でラクチン。 【auditbeat.yml】 auditbeat.modules: - module: auditd audit_rules: | -a always,exit -F arch=b32 -F auid>=1000 -F auid!=4294967295 -S execve -a always,exit -F arch=b64 -F auid>=1000 -F auid!=4294967295 -S execve - module: file_integrity paths: - /bin - /usr/bin - /sbin - /usr/sbin - /etc 【参考】 https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/6/html/security_guide/sec-defining_audit_rules_and_controls UID1000以上のシステムユーザ以外のユーザ によるコマンド実行を全て取得することが可能。 ユーザログイン認証はデフォルトで取得可能。 変更を見張りたいディレクトリを記載することで ファイル改ざん監視が可能。 audit_rules変更時に自動的にーDされると書かれているが、auditctl –lするとルールは消えてない...あれれ
  43. 43. 43 5. 最後に...
  44. 44. 44 是非、解決してもらいたい課題について ElasticsearchのタイムゾーンがUTCであることの運用課題をそろそろ解決出来るように... ログ管理DB Winlogbeat KibanaElasticsearch search Auditbeat Alerting セキュリティ担当 Mail ログファイル (Linux) イベントログ (Windows) Windowsサーバ Linuxサーバ Logstash Syslog UTM Sandbox Proxy Anti Virus Mail (MTA) File Transfer OSが保持しているタイムゾーン (JST) ブラウザが保持しているタイムゾーン (JST) ESが保持しているタイムゾーン (UTC) Index01 Index02 Index03 【ポイント②】 ログ分析ユースケースでは、取り込むデータが日々増え続ける ため、LogstashやBeatsの生成するIndexはデフォルト日次 で作成され、切り替わる。 しかし切り替わるタイミングがUTCのため日本のAM9時となる。 【ポイント①】 search文の中で時刻を範囲指定する場合、前日0時~当日0時を “gt”: “now-1d/d-9h“と”lt”: “now/d-9h”と9時間引く必要がある。
  45. 45. 45
  • yasuhiroikai9

    Apr. 20, 2021
  • masayoshisuzuki921

    Apr. 8, 2020
  • hidekikimura5

    Aug. 29, 2019
  • TakumaKawakami2

    Aug. 26, 2019
  • dcomrpc

    Jul. 28, 2019
  • yudaifujinaga

    Mar. 15, 2019
  • soskaykakehi

    Nov. 22, 2018
  • tak_c

    Oct. 17, 2018
  • MasaoOISHI

    Sep. 5, 2018
  • AkiraIto6

    Jun. 20, 2018
  • ozawaken

    Jun. 19, 2018

日本Elasticユーザグループ

Views

Total views

5,278

On Slideshare

0

From embeds

0

Number of embeds

1,020

Actions

Downloads

54

Shares

0

Comments

0

Likes

11

×