|
1
|
1 \section{現在の学科システム}
|
|
|
2 本章では現在の学科システムの問題点及び監視システムを導入する際に発生するであろう 問題点について述べる.
|
|
|
3
|
|
|
4
|
|
|
5 \subsection{問題点}
|
|
3
|
6 現在学科システムにはシステム監視,ログ収集,アラート送信などの異常検知の機能が無く,システム障害や攻撃の早期発見・事後対応が困難である.
|
|
1
|
7 実際に2021年8月にはレンタルサーバーと基幹サーバーで障害が発生した.
|
|
|
8 その際に 利用者からサーバー上で動作しているサービスが使用出来ないという報告を受けて障害に気づいた.また,該当サーバーが物理故障しており,原因調査の為ログを確認したかったがサーバーにアクセス出来なかった為調査開始に時間がかかった.
|
|
|
9 また,10月から11月にかけては学科で運用しているGitlabが脆弱性を突かれ攻撃された.実際に攻撃を受ける前に総当たり攻撃が失敗していたりユーザーに対して警告メールが送信されていたが攻撃に使用されているのに気づいたのは報告を受けてからだった.
|
|
2
|
10 本稿では,障害の早期発見や事後対応を円滑に進める為に監視システムの提案を行う.
|
|
1
|
11
|
|
|
12 \subsection{監視システムを運用する上での課題}
|
|
3
|
13 監視システムを運用していく中でアラートルールは通知される量やその精度に応じて調 整する必要があり, 障害は個人ではなく組織として対応する為,全ての変更はグループ全 体が理解しているのが好ましい.
|
|
1
|
14 しかし通常では一人がサーバーにアクセスしてCLI上での変更が必要となる.上記の方法では第三者に編集内容を伝える方法としてログなどにまとめるしか無く,また第三者はログを自分で探す必要がある.
|
|
|
15 その為学科で使用しているチャットサービスであるmattermostからアラートルールを 変更する事で属人化を防ぐ. 上記の方法だとアラートルールを共有する形で編集できる為, 作業ログをまとめる必要や第三者がそれらのログを探す手間が省ける.これにより上述した問題点を改善することが出来,属人化するリスクを抑えることが出来ると考える |
