Linuc システムアーキテクト SA02

NUMA(Non-uniform memory access):複数のCPUによって構成されるアーキテクチャ。CPUによってメモリ性能が異なるものをNUMAと呼ぶ。単一バスだとスケーラビリティがないための対策。

pinning：仮想マシンのvCPUを、物理コアに固定する方法。

リングプロテクション：

• オペレーティングシステムやドライバ、その他のアプリケーションを権限分けして動作させるための仕組み
• カーネルがリング０、その他のプログラムはリング３。（リング１，２も存在するが使っているOSはほとんどない）
• 仮想マシンの場合にリングをどう扱うか
  • バイナリトランスレーション：仮想マシン上で実行されるプログラムを逐一変換しながら実行するといった手法。センシティブ命令がほかの命令に置き換えられて実行されまる。
  • センシティブ命令：そのシステムの状態を変更したり、もしくはそのシステムの状態によって挙動が変わったりする命令
    参考：https://gihyo.jp/dev/serial/01/vm_work/0004

KVM：

• カーネルモジュールとして提供される。
• CPUがサポートする仮想化支援機能 (Intel VT-x、またはAMD AMD-V)をQEMUに対して提供する。
• 仮想メモリ、物理メモリアドレス変換のCPUハードウェア処理化 (EPT機能、VT-d機能)。
• KSM (Kernel Samepage Merging):内容が重複するメモリ上のデータを集約し、複数インスタンスで再利用する技術

QEMU：エミュレーション機能を提供。

libvirt：仮想化アプリケーションやハイパーバイザを操作するための抽象化レイヤーを提供するソフトウェア群。

Virtual Machine Manager（virt-manager）：QEMU＋KVMを操作できるGUIプログラム。裏ではlibvirtが提供するAPIを介してQEMUコマンドを発行している。

virtio：仮想I/Oデバイス (ディスク、ネットワーク、サウンド、ディスプレイ、キーボード、マウスなど) の準仮想化ドライバ機能を提供するAPI群。統一されたインターフェースを提供することで、仮想化アプリケーション開発者の負担を減らすことができる。
参考：https://endy-tech.hatenablog.jp/entry/kvm_introduction

QCOW2：

• sparseファイル
• スナップショットを取れる
• ディスク領域を拡張する際、IO性能が極端に劣化。

RAW（sparse）

• sparseファイル
• スナップショットは取れない
• ディスク領域を拡張する際、IO性能が劣化。（qcow2ほどではない）

RAW（non-sparse）

• non-sparseファイル（あらかじめ領域確保）
• スナップショットは取れない

virt-p2v：対象マシンのハードディスクからデータを吸い上げ、ssh経由で他のマシン上に仮想マシンイメージファイルを作成。
virt-v2v：外部のハイパーバイザ（主にVMware ESXi）上にある仮想マシンをKVM上で使用するためのツール。ゲストOSの種類、バージョンによりサポートされるもの、されないものがある。

cgroup：CPU、メモリ、I/Oデバイスなどのリソースを管理し、特定のグループに割り当てることができます。これにより、コンテナごとにリソースの使用量を制限する。

namespace：リソースの分離技術。PID以外にもIPC、Network等色々な種類がある。

コンテナレイヤ：コンテナ上の読み書き可能なレイヤ
イメージレイヤ：イメージを構成する読み込み専用レイヤ
参考：https://www.techscore.com/blog/2018/12/10/docker-images-and-layers/

複数コンテナにおけるイメージの共有：

• イメージレイヤは読み取り専用なので複数コンテナで利用する場合でもイメージ（レイヤ）は一つで、利用するコンテナで共有する。
• コンテナ内でイメージレイヤ部分を更新する場合、コピーオンライトによって実現する。

コピーオンライト：イメージレイヤに存在するファイルを更新する際、データをコンテナレイヤにコピーして変更を反映する。ストレージドライバによって実装が異なる。aufsドライバではファイルがコピーされるが、devicemapperドライバでは64Kバイトのブロック単位でコピーされる。

イメージとホストのファイルシステムとの関係：
OverlayFS：レイヤーを重ね合わせて結合してできるファイルシステム
参考：https://tech-lab.sios.jp/archives/21103

Dockerfile の記載方法：
FROM、RUN（レイヤを作る）、CMD（レイヤを作らない）、COPY、ENV、WORKDIR

必要十分な親イメージの選択:

• scratch：Docker が規定する最小イメージ
• distroless：不要なファイルを削除しアプリケーションの実行に必要な最小限のファイルのみを含んだコンテナイメージ。もしくはGoogleが配布している上記を実装したイメージ。

構成物 (apt/yum/dnf パッケージなど) のバージョン指定

ダウンロードキャッシュのクリア：apt updateコマンド等でpackageリストを更新すると/var/cache/apk配下にキャッシュが作成される。コンテナ肥大化の要因となるので、実行時に「--no-cache」を付与する等、キャッシュがコンテナに含まれない様に配慮する。

マルチステージビルド：

• ビルド用のイメージでアプリケーションをビルドする
• ビルドした成果物のみをデプロイ用イメージにコピー
• デプロイ用イメージはランタイムと成果物のみを格納

bind mount：「ホストマシン」上のファイルやディレクトリがコンテナー内にマウントされる

• ビルド時にCOPYの代わりにする
• データの永続化
• 成果物を配置
  参考：https://matsuand.github.io/docs.docker.jp.onthefly/storage/bind-mounts/#start-a-container-with-a-bind-mount

tmpfs：tmpfsマウントは一時的なものであり、ホストマシンのメモリ上にのみ存在。 コンテナーが停止されるとtmpfsマウントは削除されるため、そこに書き込まれたファイルを保持し続けることはできない。

• 重要な情報を含んだファイルを一時的に保存したい場合
  参考：https://matsuand.github.io/docs.docker.jp.onthefly/storage/tmpfs/

起動時の環境変数割り当て：

• docker run -e ENV=VALUE
• docker run --env-file envfile.txt
• DockerFile内のENV
• 起動時のshellで指定

複数コンテナの一括管理:
docker compose：

• 複数コンテナの Docker アプリケーションを定義・実行するツール
• コンテナ間でデータを共有するために必要なボリュームや内部通信のためのネットワークを提供

宣言的 API：サービスに実行すべき命令を伝えるのではなく、サービスのあるべき状態を指示できるAPI
突き合わせループ：k8sのReconciliation Loop

CRI（Container Runtime Interface）：

• kubeletとコンテナランタイムが通信するためのインターフェースを規定したもの
• CRIはプロトコルバッファ、gRPC API、およびランタイムで構成されている
• CRIをサポートするコンテナランタイム：Docker(dockershim + containerd),containerd,CRI-O

CNI：

• コンテナがネットワークに接続するインターフェースの標準仕様とリファレンスプラグインを提供
• CNIは、コンテナのネットワーク接続と、コンテナが削除されたときに割り当てられたリソースの削除の役割を担う
• 代表的なプラグイン：falnnel ,Calico,Canal,Weave Net

CSI（Container Storage Interface）：

• コンテナオーケストレーションツールとストレージとの間のインターフェースの標準仕様
• CSIでは、Kubernetes（コンテナオーケストレーションツール）側が、以下の3つのサイドカーコンテナを提供することになっています。
  • external-attacher： VolumeAttachmentオブジェクトを監視し、CSIエンドポイントに対してボリュームをノードにアタッチする命令を行います
  • external-provisoner： PersistentVolumeClaimオブジェクトを監視し、CSIエンドポイントに対してボリューム作成や削除の命令を行います
  • driver-register： CSI driverをkubeletに登録します
• また、ストレージベンダー側は、以下の3つのサービスを実装する必要があります。
  • Identity Service：　コンテナオーケストレーションツールがプラグインに対してCapability/Health/その他メタデータなどを問い合わせるために実装します。
  • Controller Service： ボリュームやスナップショットの作成・削除・一覧表示を行う機能を実装します。
  • Node Service： コンテナオーケストレーションツール側からボリュームをマウントする際に呼び出される機能を実装します。

参考：https://qiita.com/mamomamo/items/448a8edf6d4ccfc22bbd
　　　https://qiita.com/suzukihi724/items/7cb57eade2823e4a344f

Envoy：

• L4/L7プロキシ
• コンテナにインジェクションすることで、サービス間の通信をEnvoyが媒介しサービスメッシュを構成。（アンバサダーパターンとも）
• iptablesで出入りするトラフィックをEnvoyに吸い込む

参考：https://speakerdeck.com/kurochan/ru-men-envoy

Istio：

• Traffic Management：ルーティング、ロードバランシング、サーキットブレーカー、タイムアウト、リトライ、Fault Injection
• Observability：トレース、監視、ログ（Prometehusなどへデータを転送）
• Security：認証・認可（JWT）、暗号化（mTLS。証明書はIstioが独自発行）
• k8s同様、コントロールプレーンとデータプレーンに分かれている
  参考：https://blog.kinto-technologies.com/posts/2023-12-16-Istio-for-Application-Developers/
  　　　https://qiita.com/taisho6339/items/31aea5a1871ebd68aa35

フェデレーション方式：

• OAuth:
  • 概要: リソース所有者（ユーザー）がリソースサーバー（サービス）にアクセスするためのアクセス権をクライアント（アプリケーション）に付与するためのプロトコル。
  • 用途: 主にAPIアクセスの認可に使用されます。
  • 特徴: トークンベースの認可で、ユーザーのパスワードを共有せずにアクセスを許可します。
• OpenID Connect:
  • 概要: OAuth 2.0の上に構築された認証プロトコル。
  • 用途: ユーザーの認証と、ユーザー情報の取得に使用されます。
  • 特徴: IDトークンを使用してユーザーの認証情報を提供し、シングルサインオンを実現します。
• SAML（Security Assertion Markup Language）:
  • 概要: XMLベースのフレームワークで、認証と認可の情報を交換するための標準。
  • 用途: 主に企業内や企業間のシングルサインオンに使用されます。
  • 特徴: 認証情報をアサーションとして交換し、ユーザーが一度のログインで複数のサービスにアクセスできるようにします。

リバースプロキシ方式：

• 概要: リバースプロキシサーバーがユーザーのリクエストを受け取り、バックエンドの認証サーバーに転送して認証を行う方式。
• 用途: Webアプリケーションの前に配置され、認証とアクセス制御を集中管理します。
• 特徴: ユーザーは直接バックエンドサーバーにアクセスせず、リバースプロキシを通じて認証されます。

代理認証方式：

• 概要: 代理認証サーバーがユーザーに代わって認証を行い、認証情報をバックエンドのサービスに提供する方式。
• 用途: 主にレガシーシステムや、直接認証が難しいシステムで使用されます。
• 特徴: ユーザーの認証情報を代理認証サーバーが管理し、バックエンドサービスに対して認証済みのリクエストを送信します。

多要素認証

• 知識情報（ID、パスワード）に追加して所持情報、または生体情報を組み合わせて実施する認証
  • 所持情報：ICカード、スマートフォン、ハードウェアトークン
  • 生体情報：指紋、顔、虹彩など

多段階認証

• 要素数ではなく、ステップ数に重点を置いた認証
• 多要素とは異なり、知識情報で２段階の認証を行う場合もある（秘密の質問）

Time-Based One-Time Password (TOTP)

• アルゴリズムに基づいて 30～60 秒ごとに固有のコードが生成される認証メソッド
• スマホのAuthenticatorでよく見るやつ

パスワードレス認証

• パスワードを使用せずにユーザー認証を行う方法
• 知識情報ではなく、所持情報や生体情報で認証
• マジックリンク：「1回限り利用可能」「一定時間のみ有効」なログイン用の認証リンクの通知を行い、利用者本人が通知された認証リンクをクリックすることでユーザー認証を完了させる仕組み

FIDO認証(Fast Identity Online)

• 標準規格団体である「FIDO Alliance」によって制定された、公開鍵暗号方式を用いてパスワードに依存しない認証方式
• 「FIDO UAF」「FIDO U2F」という規格に加え、この2つの規格を統合・拡張した新仕様として「FIDO2」が2018年に発表
• 。FIDO2では、FIDO2対応のブラウザと、認証器（スマートフォンやPC等のデバイス）を使用することで認証を行う。

参考：https://www.ogis-ri.co.jp/column/themistruct/c106538.html

FreeIPA：

• LDAPおよびKerberosによる認証基盤で、Windows環境におけるActive Directoryのような立ち位置のもの
• 主な機能は以下のとおりです。
  • ユーザ、ホスト、サービスのIDを集中管理する
  • Kerberosでの認証によるシングルサインオン
  • Active Directoryと連携し、ADにログインしているユーザにシングルサインオンを提供する
  • 複数マシンにFreeIPAを導入し、マルチマスタレプリケーションを構成する
  • Web UIおよびコマンドラインクライアント、XMLRPC APIの提供
  • 証明書の発行
  • ドメイン内向けDNSの管理
  • 2要素認証（OTPトークンによるワンタイムパスワードも可能）
  • 接続元のシステムを考慮するホストベースアクセス制御(HBAC)
  • 従来システムとの互換性を実現するための互換LDAPツリーの提供
  • 複数FreeIPAサーバ構築時の負荷分散

任意アクセス制御（DAC）

• ユーザー自身が、自分が所有するリソース（ファイルやディレクトリなど）に対するアクセス権を設定。
• 自由に設定できるため柔軟性は高いが、セキュリティリスクが高まる。また、全体としての一貫性（セキュリティポリシー）を保つのは難しくなる。

強制アクセス制御 (MAC)

• 管理者が全てのアクセス制御ポリシーを設定し、ユーザーはこれを変更できない。
• セキュリティレベルが設定され、ユーザーとリソースのセキュリティラベルに基づいてアクセスが許可される。
• 高いセキュリティが求められる環境（例：軍事、政府機関）で使用される。

ロールベースアクセス制御 (RBAC)

• ユーザーの役割（ロール）に基づいてアクセス権を設定。
• 役割ごとに一貫した権限を付与し、管理が容易。
• 企業や組織で広く使用され、効率的なアクセス管理が可能。

属性ベースアクセス制御 (ABAC)

• ユーザーやリソースの属性に基づいてアクセス権を設定。
• きめ細かいアクセス制御が可能で、複数の属性を組み合わせてポリシーを設定。
• 動的な環境や複雑なアクセス要件に対応。

Samba：

• マイクロソフトのWindowsネットワークを実装したOSS
• Samba4(2012)より、Active Directoryドメインのドメインコントローラー機能がサポート
  参考：https://www.rem-system.com/samba-410-ad/

ドメイン参加
参考：https://www.rem-system.com/samba-add-ad/

SELinux：

• 強制アクセス制御 (MAC) を実装し、管理者が定義したセキュリティポリシーに基づいてアクセスを制御。
• プロセスとリソースにラベルを付け、それに基づいてアクセス権を決定。
• 詳細な制御が可能で、特定のプロセスが特定のリソースにどのようにアクセスできるかを細かく設定
• 高度なセキュリティが求められる環境で、システム全体のセキュリティを強化するために使用

AppArmor：

• 名前ベースの強制アクセス制御 (MAC) を実装し、ファイルパスに基づいてアクセス制御を行う。
• 設定が簡単で、特定のアプリケーションに対するアクセス制御をプロファイルとして定義。
• 柔軟性があり、特定のファイルやディレクトリに対するアクセス権を詳細に設定できる。
• システムやアプリケーションのセキュリティを簡単に強化するために使用さる。特にUbuntuやSUSEなどのディストリビューションでデフォルトで使用されている。

seccomp/bpf：

• システムコールのフィルタリングを行い、許可されたシステムコールのみを実行可能にする。
• 軽量なサンドボックスを提供し、プロセスの動作を制限。
• 柔軟性があり、特定のシステムコールを許可または拒否するフィルタを設定できる。
• コンテナやセキュアなアプリケーション実行環境で利用される。

リフレクション攻撃：

• UDPのコネクションを張らない性質を利用して、インターネット上のサーバーに偽装した大量のリクエストを行い、送信元を偽装することで、大量の小さなリクエストをインターネット上の標的のサーバーに送信するサイバー攻撃
• DNS、NTP、SSDP、SNMPなどUDPの各種プロトコルが使用される

SYN flood（ハーフオープン攻撃）：

• 最初の接続要求（SYN）パケットを繰り返し送信することにより、標的となるサーバーで利用可能なすべてのポートを圧倒し、標的となるサーバーが正当なトラフィックに応答するのを非常に遅くする、またはまったく応答しなくなるようにする。

オープンリゾルバ：

• 外部の不特定のIPアドレスからの再帰的な問い合わせを許可しているDNSサーバーのこと
• DDoS攻撃の踏み台として悪用されることがある

DDoS

• Memcached：Memcached 攻撃は増幅攻撃の一種で、攻撃者はHTTP GET要求を脆弱な Memcached サーバーに送信。これらの脆弱なサーバーから目的のターゲットにUDPパケットが送られる
  https://www.akamai.com/ja/glossary/what-is-a-memcached-ddos-attack

• NTP： 攻撃者は IP アドレスを偽って脆弱な NTP サーバーに要求を送信します。その結果、NTP サーバーは通常よりもはるかに大量の応答を返す
  https://www.akamai.com/ja/glossary/what-is-an-ntp-amplification-attack

• DNS：

  • DNS フラッド攻撃は、膨大な数のクエリーを送信して DNS ネームサーバーのリソースを枯渇させる。（DNSサーバーを対象とした攻撃）
  • ソースIPアドレスを偽装したDNSリクエストをDNSサーバに送信し、DNSサーバから攻撃対象のサーバ（偽装したソースIPアドレスのサーバ）にDNSのレスポンスを送信させることで、攻撃対象のリソースを消費させる攻撃。
    https://www.akamai.com/ja/glossary/what-is-a-dns-ddos-attack

不正アクセス手法:

• SQL インジェクション：脆弱性のあるアプリケーションに対して不正なSQLコマンドを注入し、データベースにアクセスする攻撃。
• コマンドインジェクション：脆弱性のあるアプリケーションに対して不正なOSコマンドを注入し、システムにアクセスする攻撃。
• ディレクトリトラバーサル：非公開ファイルに不正アクセスし、情報の窃取や改ざんを行うサイバー攻撃
• バッファオーバーラン：バッファオーバーフローを引き起こすコードを悪用し、外部からわざと想定より長いデータを与えることでプログラムを異常終了させたり、攻撃用のコードを送り込んで実行させたりする攻撃手法
• リスト型攻撃：何らかの方法で入手したアカウントとパスワードが記載されたリストをもとにウェブサービスへの不正アクセスを試みる攻撃

• ペネトレーションテスト

  • Greenbone Vulnerability Manager(GVM)：OpenVASの進化系。セキュリティスキャンと脆弱性管理を行うためのオープンソースのセキュリティツール
  • OWASP ZAP：オープンソースのWebアプリケーションセキュリティテストツールで、脆弱性を診断するための強力な機能を提供。プロキシサーバーとして機能し、Webトラフィックをインターセプトして分析することで、脆弱性を特定。

• 脆弱性の報告されたパッケージ (パッチ) の検出:

  • Clair：appc および docker コンテナにおける脆弱性の静的分析を通じてコンテナのセキュリティを監視するツールを提供
  • Katello：ソフトウェアライフサイクル管理を提供。
  • Vuls：脆弱性検知ツール

• 規格への適合確認:

  • OpenSCAP：脆弱性の診断や、その修正を行えるツール。
  • SCAP：Security Content Automation Protocol：セキュリティ設定共通化手順。NIST（アメリカ国立標準技術研究所）が制定したセキュリティ関連の標準仕様。

• コンテナイメージのスキャン:

  • Trivy：コンテナイメージの脆弱性診断ツール。yumやapt等でインストールされたパッケージを対象に診断（ソースコードからビルドされた場合は検知対象外）。動作中のコンテナも対象外。

パケットシグネチャを使用したフィルタリング：

• IDS/IPSで使用される検知方式。「シグネチャ」と呼ばれる不正アクセスの攻撃パターンのデータベースを用いて判断する。

DPI（Deep Packet Inspection）：

• HTTPなど最上位のプロトコルが運んでいるデータ本体部分を含めて検査を行うことで、ヘッダ情報だけでは判別できない挙動を検知することが可能。（Webアップロードを検知）
• セキュリティ対策以外にも、通信の種類に応じてQoSを実施したり、モバイル通信で実施されている特定のSNSだけデータ量無料を実現したり、広告表示に使用したりと様々な活用が行われている。

DDoS Mitigation Device：
- FW、UTMなどに搭載されているDDoS防御機能？
- レート制限：特定のプロトコル・ポートの通信が閾値を超えた場合に通信を遮断
- Syn flood 防御：デバイス側でSYNに代理応答（SYN/ACKを返答）。後続のACKが返ってこない場合に、Syn floodと判断。

ISP の Routing Blackhole：

• 悪性のトラフィックまたは好ましくないトラフィックを、内部ゲートウェイ・プロトコル・ドメインを介して「ブラックホール」（null0 などの Null インターフェース）にリダイレクトし、そこで永久的に破棄する。
• ネットワーク管理者は特定の送信元 IP アドレスからのすべてのトラフィックまたは特定の宛先 IP アドレスへのすべてのトラフィックをブラックホールにリダイレクトさせる

サンドボックス：

• 仮想環境内でのファイルやプログラムの挙動やふるまいをもとに脅威を検知する
• シグネチャがまだ登録されていない未知の脅威であっても、効果的に検知することができる

暗号化ファイルシステム、ストレージ:
- LUKS（Linux Unified Key Setup）：ディスク暗号化仕様。バックエンドにdm-cryptを用いて実装。
- dm-crypt：Linuxカーネルの透過型ディスク暗号化サブシステム。ディスク全体(リムーバブルメディアを含む)、パーティション、ソフトウェアRAIDボリューム、論理ボリューム、およびファイルを暗号化できる。
- TPM（Trusted Platform Module）：安全な暗号プロセッサの国際規格。暗号鍵をデバイスに統合することによりハードウェアを保護する専用のマイクロプロセッサ。セキュアブート、キーストレージ、乱数生成など様々なセキュリティアプリケーションで使用する。

外部アクセスポート/デバイスの制限 (USB ポートの利用制限など)：

• 外部アクセスポートを制限：iptables、firewalld等で制限？
• usb利用制限：usb_storageカーネルモジュールをブラックリストに追加

• 使用しない機能や設定を削除し、潜在的な脆弱性を低減する。
  • 不要なユーザー・アクセス権の削除
  • 使用していないサービスやソフトウェアの検出
  • 仮想マシン/コンテナに対する権限、リソース設定
• いわゆる一般的な要塞化の話かな？

Linux 監査フレームワーク

• CAPP (Controlled Access Protection Profile) に準拠した監査システム
• カーネルが報告するイベントを受信し、ログファイルに書き込む

ファイルアクセス監視

# -wで特定のファイルへのアクセスをログに記録。
# r:読み込み、w:書き込み、x:実行、a:属性変更、未指定は全部
auditctl -w /etc/passwd -p rwxa
auditctl -w /etc/security/

# cat /etc/audit/audit.rules 
-w /etc/audit/audit.rules -p rwxa
-w /etc/security/

システムコール監視

# -aを付けるとシステムコールを監査 chmodシステムコールを監査する例
auditctl -a entry,always -S chmod

監査ログのクエリ

# 特定のPIDに関するイベントを検索
ausearch -p 1

# 検索を容易にするためにKEYを付与(-k)すると、キーで検索可能
auditctl -w /etc/passwd -p rwxa -k KEY_pwd
ausearch -k KEY_pwd

レポート出力

# 異常なイベント(※)を素早く検知可能
# ※：ネットワークインターフェイスがプロミスキャスモードに設定された
# 　　プロセスまたはスレッドが ENOMEM エラーで異常終了した、など
aureport -n

参考：https://wiki.archlinux.jp/index.php/Audit_フレームワーク

ホスト型侵入検知システム (HIDS) ：

• Host-based Intrusion Detection System
• NIDSはネットワークを監視、HIDSはコンピュータの中を監視

ファイル改ざん検知:

• AIDE
  • Advanced Intrusion Detection Environment
  • オープンソースの侵入検知システム

  # インストール
  dnf install aide
  
  # 初期データベース作成
  aide --init
  mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz
  
  # 設定の変更は/etc/aide.confを編集
  # CONTENT：内容のチェックのみ実施
  # CONTENT_EX：内容はチェックするが、属性（タイムスタンプ、パーミッションなど）は除外
  # DATAONLY：データの内容だけではなく、属性の変更も検知
  # PERMS：パーミッションを監視
  # LOG：変更をログに記録する
  # LOG+ANF+ARF（Allow New Files、Allow Removed Files）：ファイルの作成、削除もログに記録
  # !：監視対象から除外
  /etc/passwd$     CONTENT_EX
  /var/log/lastlog$ PERMS
  !/usr/src
  
  # チェック実行
  aide --check
  
  # データベース更新
  # /var/lib/aide/aide.db.new.gzが生成されるのでnewを削除
  aide --update
  mv -f /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz
  

• Tripwire
  • Tripwire,Incの商用製品もあるが、OSS版もある

  # インストール
  dnf install tripwire --enablerepo=epel
  
  # サイトキー、ローカルキーの作成
  tripwire-setup-keyfiles
  
  # 設定の変更は/etc/tripwaire/twcfg.txtを編集
  # 編集後、サイトキーで署名
  twadmin --create-cfgfile --site-keyfile /etc/tripwire/site.key
  　--site-passphrase <サイトパスフレーズ> /etc/tripwire/twcfg.txt
  
  # ポリシーファイル（/etc/tripwire/twpol.txt）で監視対象を指定
  # 同様に署名
  twadmin --create-polfile --cfgfile /etc/tripwire/tw.cfg
  　--site-passphrase <サイトパスフレーズ> /etc/tripwire/twpol.txt
  
  # データベース初期化
  tripwire --init --local-passphrase <ローカルパスフレーズ>
  
  # チェック実行
  tripwire --check
  
  # 結果確認
  twprint --print-report --twrfile <レポートファイルのpath>
  
  # データベース更新
  tripwire --update --accept-all --local-passphrase <ローカルパスフレーズ>
  　--twrfile <レポートファイルのpath>
  
  # ポリシー更新
  tripwire --update-policy --site-passphrase <サイトパスフレーズ>
  　--local-passphrase <ローカルパスフレーズ> /etc/tripwire/twpol.txt
  

• 自動化： どちらもジョブ機能等はないのでcronでチェックを定期実行

マルウェア検知:

• chkrootkit（ルートキット検知ツール）

  # インストール
  dnf install chkrootkit
  
  # 設定ファイル（/etc/chkrootkit.conf）
  # RUN_DAILYをtrueにすると、cron.dailyで定期実行
  RUN_DAILY="false"
  RUN_DAILY_OPTS="-q"
  DIFF_MODE="false"
  
  # 実行
  chkrootkit
  

• rkhunter（ルートキット検知ツール、ルートキット以外も検知できる）

  # インストール
  apt-get install rkhunter
  rkhunter --update
  
  # 設定ファイル（/etc/rkhunter.conf）
  LANGUAGES=en
  WEB_CMD="/bin/false" (update取得するならcurlに変更)
  UPDATE_MIRRORS=0 -> UPDATE_MIRRORS=1 (as default value)
  MIRRORS_MODE=1 -> MIRROS_MODE=0 (as default value)
  PKGMGR=NONE -> DPKG
  
  # コンフィグチェック
  rkhunter --config-check
  
  # データベース更新
  rkhunter --update
  
  # チェック
  rkhunter --check --skip-keypress
  

OSSEC：

• ホスト型IDSのOSS
• 機能： ログ解析と整合性チェック、Windowsレジストリの監視、ルートキットの検出、リアルタイム警告、アクティブレスポンス（異常イベント検知時に任意のスクリプトを実行する機能）
• 構成要素：
  • マネージャ：ファイル整合性データベースや各種設定ファイル、イベントやログ等を保有。
  • エージェント：監視対象システムにインストール。エージェントが監視対象システム内の情報を収集し、マネージャに転送。セキュリティ確保のため、特権レベルの低いユーザで実行され、隔離された領域（chroot jail）で実行される。
  • エージェントレス：エージェントをインストールせずSSH接続して監視。ファイル整合性チェックを実施できる。

アンチウィルスソフトの設定 (監視対象の選定など)

• OSSだとClamAV？
• 監視対象の選定
  • DB、およびDBに関連するファイルはスキャン対象外とすることが推奨されている
    • DBは頻繁に更新されるため、オンアクセススキャンの頻度が高くなる
    • 巨大なDBやREDOログをスキャンすると時間がかかる。ウィルス対策ソフトがDBやREDOログファイルをロックしてしまうと、DB破損の可能性がある
    • ウィルス対策製品のバグ（誤検知）でDB破損の可能性
  • 大きなファイル（ISOや仮想マシンのイメージファイル）はスキャン対象から外す
    • メモリ上にファイルを展開し、メモリが足りない場合テンポラリファイル（/tmp）などを用いてスキャンを行う
    • メモリやテンポラリディスクの急激な圧迫はシステム全体の安定動作に影響を及ぼす
  • 圧縮ファイルのスキャン要否の検討
    • スキャン時に圧縮ファイルを解凍してスキャンを行うため、上記同様メモリやテンポラリファイルを圧迫する可能性がある。
    • 高圧縮（多段階の圧縮）も要注意。Zip Bomb攻撃と呼ばれる攻撃もある。
    • スキャンサイズの上限や圧縮ファイルの階層指定を検討
  • ファイルサーバは通常スキャン対象外にする
    • 複数のクライアントからスキャンすると多重スキャンになる
    • スキャン専用のサーバを用意するなどの対策を検討
    • ストレージベンダ専用のスキャンインタフェースを使用（OnTAP、CAVAなど）
    • スキャンを分割する
    • バックアップを用いてスキャンを行う
      参考：https://security.sios.jp/vulnerability/antivirus-security-20161108/

ネットワーク型侵入検知システム (NIDS) ：

• ネットワークを監視するIDS

• Snort

  • オープンソースのネットワーク型のIDS
  • ソースで提供されているため、ダウンロードしてmakeする必要がある
  • libpcap、libpcre、pcre‐devel、dnet header、daq、zlib、LuaJIT、openssl-develなどが必要

  # 設定ファイルは/etc/sysconfig/snort
  INTERFACE=eth0（インタフェースを指定）
  
  # ルールセット（シグネチャ）は公式サイトにコミュニティ版があるので
  # ダウンロードして配置
  /etc/snort/sid-msg.map
  /etc/snort/rules/community.rules
  

  参考：https://qiita.com/Brutus/items/b11c3324492a4e25a152

セキュリティ情報・イベント管理解析ツール (SIEM):

• 複数ソースから集約したログの正規化
  • ノイズのフィルタリング
  • カテゴリ別に分類、インデックスを付与
• 相関分析によるインシデント判定
  • 異なる複数の端末やアプリケーションなどが記録するログの相関（コリレーション）を分析し、ネットワーク上で発生している一連の問題の関連性を把握する分析手法

参考：https://www.redhat.com/ja/topics/security/what-is-SIEM

プッシュ型

• 監視対象にエージェントをインストールし、各エージェントが監視サーバに対してデータを送信する構成
  ‐ 監視サーバ側の構成変更不要
• 外部サーバからのアクセス不要（インバウンドを開ける必要なし）
• SaaS型は基本的にプッシュ型（Datadog,Mackerelなど）

プル型

• 監視サーバ側で監視対象の設定を行い、監視対象からデータを集めてくる構成
• 古くからある監視製品はこちらが多い（Nagios,Zabbix,Prometheusなど）
• エージェントレス構成もあるが、取得項目が制限される
• エージェント/エクスポーターを使用して各種詳細データを収集

収集結果のストア方式

• 時系列データベース
  • 時間によってインデックス化されたデータの集合（主キーがタイムスタンプ）
  • 基本的にCRが中心。UDも可能だが性能が落ちるなど制約あり。

参考：https://yasuharu519.hatenablog.com/entry/2017/12/16/215855

IPMI：

• Intelligent Platform Management Interface
• コンピュータシステムやサーバのリモート管理と監視を行うために標準化されたハードウェア管理インタフェースおよびプロトコル
• IPMIに準拠したサーバが必要

#Health Event Log基本情報の取得
ipmitool sel list > ipmi-event.log

SNMP：

• Simple Network Management Protocol
• バージョン：v1,v2c,v3

# 収集例
snmpwalk -v 2c -c public localhost .1.3.6.1.4.1.2021.9.1.2.1

SNMP version 3

• ユーザー認証の流れ

  1. (→)：監視対象へエンジンIDを要求
  2. (←)：エンジンIDを送信
  3. (→)：エンジンIDを利用しユーザ名、パスワード、暗号化パスワード、OID等を暗号化して送信
  4. (←)：OIDに紐づく情報を暗号化して送信

• アクセス制御

  • VACM（view-based Access Control Model）を利用
  • ユーザ毎にMIBオブジェクトに対するアクセス制御を実施

Zabbix

• 構成要素
  • サーバー：いわゆる管理サーバ
  • エージェント：監視対象にインストールし、データを収集、サーバに送信。
  • プロキシ：一つ以上の監視対象からデータを収集し、サーバーへ送信（中継機能）
  • javaゲートウェイ：JMXアプリケーションの監視をネイティブにサポート
  • Sender：コマンドラインユーティリティ
• 集約方式：
  • サーバー⇔プロキシ⇔エージェントの階層構造にすることで、サーバーの負荷集中を軽減
  • プロキシで一時的にデータを保管できるが、最終的にはサーバーに集められる
• アイテム：
  • タイプ：監視種別のこと。（エージェント、シンプルチェック、SNMP、IPMI、JMXなど）
  • キー：個別の監視設定？

参考：https://www.zabbix.com/documentation/2.2/jp/manual/concepts
　　　https://www.scsk.jp/product/oss/tec_guide/zabbix/1_zabbix5_2.html

Prometheus

• 構成要素
  • Prometheus サーバー：監視サーバ
  • Node exporter：監視エージェント
  • Pushgateway：生存期間の短いサーバー等に対してプッシュ型のメトリクス収集を提供。
• サービスディスカバリ
  • 監視対象の情報を自動的に取得してくる仕組み
    参考：https://knowledge.sakura.ad.jp/27501/#Prometheus-3

Fluentd (td-agent)

• Inputプラグイン：

<source>　　　　#Inputプラグインは<source>ディレクティブで指定
@type tail 　　 利用プラグインの指定
tag 　　　　　　タグ名
path 　　　　　 ログファイルパス
pos_file 　　　 指定ファイルに最後に読み込んだ位置を記録します。
format 　　　　 ログのフォーマット ’/’で囲まれた正規表現を指定
time_format 　　時間フィールドのフォーマット(strftime形式)
</source>

• Outputプラグイン：

<match タグ名> #outputプラグインで指定するディレクティブ
　　　　　　　　#inputプラグインに指定したタグ名を記述する
@type file 　　#fileプラグインの設定
path 　　　　　出力ログファイルパス
time_slice_format 　　出力ファイル名+付与される名前(デフォルト%Y%m%d）
time_wait 　　 出力ファイルがローテーションする前に待つ時間(デフォルト10分)
<バッファの設定> 後述
</match>

• Filterプラグイン:

<filter タグ名>  #指定したタグを対象にフィルタ処理
  @type parser　# parserは独自パーサーを定義<parse>~</parse>
  key_name log
  <parse>
    @type regexp
    expression /^(?<host>[^ ]*) [^ ]* (?<user>[^ ]*) \[(?<time>[^\]]*)\] "(?<method>\S+)(?: +(?<path>[^ ]*) +\S*)?" (?<code>[^ ]*) (?<size>[^ ]*)$/
    time_format %d/%b/%Y:%H:%M:%S %z
  </parse>
</filter>

• Buffer
  • 性能と信頼性向上
    • まとめて出力
    • 出力先の一時的な障害に対応
    • オンメモリとファイルの指定が可能

    buffer_type memory
    buffer_queue_limit 64
    buffer_chunk_limit 8m
    

参考：https://www.sraoss.co.jp/wp-content/uploads/files/event_seminar/material/2016/osc2016_tokyo_spring.pdf

分散トレース

• マイクロサービスのように複数のサーバーにまたがるトレースを追跡・監視する仕組み
  • TraceID：コールパス全体に発行
  • SpanID：各APIコールに発行

OpenTelemetry

• サービスインストゥルメンテーション（パフォーマンスを測定する方法）のオープンソースプロジェクト
• テレメトリーデータを収集し、バックエンドプラットフォームに送信する方法を標準化。保存や可視化は対象外（JaegerやPrometheusを利用）
• Java、Go、Pythonなどの様々な言語用のSDKを含む、仕様、アプリケーション・プログラミング・インターフェース（API）、ライブラリ、およびインテグレーションで構成

collector：データ管理システム。Receivers、Processors、ExportersのPipelineで構成。

• Receivers：1つ以上のソースからテレメトリーデータを受け取るための機能
• Processors：Receiverから流れてきたデータを受け取り、Batch処理やFilter Processorを設定し、次の段階に送るデータを選択したりする
• Exporters：Processorsから送られてきたデータを、送信先のバックエンドが対応しているデータ形式に変更し、送信

バックエンド：

• Jaeger：テレメトリーデータを収集し、それを可視化、分析するUI
• X-ray：AWSのサービス

参考：https://zenn.dev/hkdord/articles/aws-open-distro-for-opentelemetry-xray

zabbix

• 通知：メール：SMS。Jabber、Ez Texting、カスタムスクリプト

参考：https://www.zabbix.com/documentation/2.2/jp/manual/config/notifications

Prometheus

• 通知：
  • alertmanagerへ通知

  alerting:
    alertmanagers:
    - static_configs:
      - targets:
        - 'localhost:9093'
  

  • メール、webhook

参考：https://changineer.info/server/monitoring/monitoring_prometheus_rule_alert.html

Grafana - Zabbix連携
https://qiita.com/_zaiko/items/96eb2ce5ca3ffb73697a

Grafana - Prometheus連携
https://knowledge.sakura.ad.jp/12058/

Grafana - Jaeger連携
https://grafana.com/docs/grafana/latest/datasources/jaeger/

カナリアテスト

• カナリアリリース（一部のユーザにのみ新バージョンをアクセスさせる手法）を用いて本番環境でテストを行う手法

シャドーテスト

• 本番トラフィックをミラーリングしてテスト環境で再現
  • メリット：本番環境に影響がない、本番環境の負荷でテスト可能
  • デメリット：コスト/運用オーバーヘッド、外部連携時の不具合（決済処理など）

インプレース

• 旧バージョンを停止し、新バージョンをデプロイする方法
  • メリット：シンプル、下位互換性の問題を回避
  • デメリット：ダウンタイムが発生

ローリングアップデート

• 実行中のアプリケーションのサブセットを更新し段階的にデプロイする方法
  • メリット：ダウンタイムが無い、ロールバック可能
  • デメリット：時間が掛かる、下位互換性が必要

ブルーグリーンデプロイ

• 旧環境（Blue）と新環境（Green）を用意し、LBで切り替える方法
  • メリット：ダウンタイムなし、即時ロールバック可能、環境分離
  • デメリット：コスト、下位互換性がないとロールバックできない（データに不整合）

参考：https://zenn.dev/hi_ka_ru/articles/deploy-test-pattern-20240513

リリースゲート

• サービスをリリースする際の条件(もしくはリリース後の条件)を、外部ツールが返した値を元に設定できる機能

参考：https://qiita.com/taminami/items/bd1ecd0e61166045ac7b