本システムは、Terraformによるインフラコード化、Ansibleによる構成管理自動化、そしてAWSへの環境構築を目標とした、検証用モックプロダクトです。
使用している技術をアウトプットがてらまとめます。 まずは改ざん検知ツールのAIDEについてです。 Tripwireが有名な改ざん検知ツールなのですが、現在は更新されていないようです。AlmaLinuxでも標準インストールできるので、今回はAIDEを使用しました。 AIDEとは？ 正式名称は「 Advanced Intrusion Detection Environment 」でAIDEというようですね。 ``` dnf install aide ``` 私の環境では下記のような形でした。 ``` Name : aide Version : 0.19.2 Release : 4.el10_2.1 Architecture : x86_64 Size : 405 k Source : aide-0.19.2-4.el10_2.1.src.rpm Rep ository : @System From repo : appstream Summary : Intrusion detection environment URL : https://github.com/aide/aide License : GPL-2.0-or-later Description : AIDE (Advanced Intrusion Detection Environment) is a file : integrity checker and intrusion detection program. ``` 現在のファイルやフォルダの構成、パーミッションをハッシュ化し、比較することで改ざんを検知する動作となっています。 なので、まずは比較用に現在のデータのハッシュ値を計算します。 ``` aide --init ``` 上記のコマンドで初期データを作成します。 ただ、このままでは比較用に使用することはできません。 デフォルトの動作で、"/var/lib/aide/aide.db.gz"のファイルを基準とします。 初期データを作成した際は「aide.db.new.gz」というファイルが作成されるので、 ``` mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz ``` で基準となるデータを作成する必要があります。 なお、これらの設定は"aide.conf"によって変更することも可能です。 ``` aide --check ``` 上記コマンドで基準のデータと、現在のファイル構成を比較します。 問題なければ、 ``` AIDE found NO differences between database and filesystem. Looks okay!! . . (省略) ``` として、変更がない旨のメッセージが表示されます。 変更が確認されると ``` AIDE found differences between database and filesystem!! Summary: Total number of entries: 39621 Added entries: 3913 Removed entries: 1 Changed entries: 26 ``` のように変更があった内容を表示してくれます。 ※動作確認中の内容なので、変更された内容が多いです。 上記の内容は、標準出力にも出力されますが、"/var/log/aide/aide.log"に書き込まれるので、どちらかで確認します。 基準データを更新する場合は、 ``` aide --update ``` で初期データを作成した際のように基準データが作成されるので、mvで名称を変更すれば、以降のchekでは検知されなくなります。 どのふぉるだを参照するかは「aide.conf」で設定することが可能です。 使用する機能に応じて、改ざんを確認したい内容は変わってくると思うので、 想定する構成ごとに検討が必要になると思います。 一点注意なのが、自動で起動するツールではないので、定期的に実行するような場合は、cronやsystem-timerで自動実行されるように設定しないといけないです。
記載の日付がだいぶ空きました。 具体的には1ヶ月程度です・・・ 監視基盤は予定通りpoometheusとGrafanaとなりました。 こちらは特に問題なく構築完了です。 監視サーバーにPrometheusをインストールし監視対象にNode_exporterをインストールしメトリクスを取得できればOKです。 ただインストールしただけなので、割愛です。 結局苦労したのは、データのバックアップでした。 DBのバックアップを取得cronでの自動実行をゴールとして作成を始めたのですが、まぁこれがなかなか上手くいきませんでした。 当初の予定では下記の流れでした。 DB-server | | mariadb-backup+rsync+restic | Backup-server（こちらからスクリプトで実行） RDSの動作を想定して、バックアップサーバー側でスクリプトを実行したかったので、上記の形にしました。 また、せっかく作成するので、ただバックアップを圧縮して保存するだけではと考え、色々バックアップツールを探していたのですが、後々AWSに移行することを踏まえて保存先をS3にも指定可能なresticを採用しました。 ※ここで少し構成を複雑にしたのが、全ての原因でした。 初めてだから、簡単な構築にすればよかったのです・・・ というわけで作成を始めたのですが、ユーザー権限が一番の問題でした。 root権限ですれば全て解決ですが、それではセキュリティ上好ましくありません。乗っ取られた際などに全てのデータを好きなようにされてしまいます。 ということで定石だと思うのですが、バックアップ用のユーザーを作成しました。 ここで問題だったのは、mariadb-backupとrysnc+resticの権限の兼ね合いです。 最小権限で絞りたかったので、両方のコマンドが実行できる権限が必要です。 当然mariadbの実行ユーザーとバックアップ用のユーザーは別です。 ということでPermission Denyが頻発しました。 ACLを設定してみたり色々してみたのですが、最終的に断念しました。 最終的には以下の構成になりました。 DB-server（こちらからスクリプトで実行） | | mariadb-dump+restic | Backup-server rsyncを使用しない構成です。 とりあえずできないと話にならないと思い、少しシンプルに変更しました。AWS移行時はまた考えます。 mariadb-backupについてもcron実行時にsockへのPermission Denyが発生し、どうにもならなかったので、mariadb-dumpに変更しました。 とりあえずできるようになったので、バックアップについては一旦これで完成とします。
１点機能を忘れていました。 画像の挿入ができなかったので、AIに作ってもらいました。 ○サンプル画像  ライセンスフリーのものを使用しています。 これで機能的には完成だと思います。 ※追加したい機能がでてきたら考えます。 監視基盤が整ったら、また新しいアプリを作ってもらおうと思います。 負荷テスト用のWEBサイトがあったほうがいいですね。
構築した検証用環境に下記を追加、変更しました。 ・記事の編集、削除機能の追加 ・ログの出力先変更 ・DBのスロークエリを出力するように変更 ○詳細 ・記事の編集、削除機能の追加( こちらはAIに作成してもらい適用しただけなので割愛) ・ログの出力先を変更 DjangoとFastapiのログの出力先を外部ファイルに変更しました。 systemdのユニットファイルに下記を追加しました。 Gunicorn側 ``` --access-logfile /var/log/gunicorn/access.log \ --error-logfile /var/log/gunicorn/error.log \ --error-logfile /var/log/gunicorn/error.log \ ``` Uvicorn側 ``` --access-log \ --log-level info \ StandardOutput=append:/var/log/uvicorn/access.log StandardError=append:/var/log/uvicorn/error.log ``` 特に問題なく出力を確認できました。 ・DBのスロークエリを出力するように変更 MariaDBを使用していますが、スロークエリのログを出力するように変更しました。 まずはスロークエリの出力の有効化 MariaDBのコンソールにログイン後以下のコマンドを実行します。 ``` set global slow_query_log=1; show global variables like 'slow_query_log%' ``` 上記でslow_query_logがonになっていれば有効化は完了です。 mariadb-server.cnfでは下記を追加します [mariadb] slow_query_log slow_query_log_file=/var/log/mariadb/slow.log Mariadbを再起動して正常に動作していれば作業完了です。 ``` sudo systemctl restart mariadb ``` 出力先に指定した箇所にログが出力されるようになります。 後はログローテーションの見直しを行って概ね作業完了になります。 次は監視基盤の作成を考えています。 prometheusとgrafanaでの監視、node_exporterでのメトリクス取得、alertmanagerでの通知を今のところ考えています。
本日、テスト用のサーバー環境が完成しました。 Ansibleでサーバー構築を半自動化しました。 なぜ半自動化なのかは達成できなかった点で・・・ プログラムについては、geminiに丸投げでの作成となりましたが、ある程度のものができたと感じています。 達成できなかった点 本日、テスト用のサーバー環境が完成しました。 Ansibleでサーバー構築を半自動化しました。 なぜ半自動化なのかは達成できなかった点で プログラムについては、geminiに丸投げでの作成となりましたが、ある程度のものができたと感じています。 ``` python3 -m venv venv pip install -r requirements.txt ``` お決まりのやつです。 またSE linuxについても手動で実行しました。 nginxをリバースプロキシに使用しているので下記のコマンドになります。 ``` setsebool -P httpd_can_network_connect on setsebool -P httpd_can_network_connect_db on setsebool -P httpd can_network_relay on ``` またSE linuxの認識するデフォルトユーザーの設定も変更しました。 デフォルトでは未登録ユーザーはunconfined_uとなり、SE linuxの影響を受けないユーザーなので、user_uに変更しました。 ``` semanage login -m -S targeted -s "user_u" -r s0 __defalut__ ``` 地味に苦労したのは、Djangoでした。 今回勉強がてら初めて使用したので、当たり前ですが、ユーザーのログイン画面のCSS等の静的ファイルが読み込めませんでした。 Django側で指定が必要で、下記のコマンドで静的ファイルを出力する必要がありました。 ``` python manage.py collectstatic --noinput ``` あとは、Djangoとnginxで静的ファイルの位置を指定してあげれば、問題なく確認できました。 SE linuxの設定は以前勉強していた際にある程度操作できたので、コンテキストを変更することで対応しました。 ``` semanage fcotext -a -t httpd_sys_conten_t '<静的ファイルのディレクトリ>' ``` 本番環境は、構築の勉強がてらAWS環境を想定しているので、準備でき次第取り掛かろうと思います。 ログの期間やバックアップの設定等まだ確認が甘いところがあるので・・・