# HG changeset patch # User kiyama # Date 1681352306 -32400 # Node ID 02066b6bd6e67cd4d42b0e6dab3b03b6481de6e8 # Parent c8ffd012e8abfc9ed1e63ae7a2875df80619c02a add 2022 diff -r c8ffd012e8ab -r 02066b6bd6e6 Paper/fig/.DS_Store Binary file Paper/fig/.DS_Store has changed diff -r c8ffd012e8ab -r 02066b6bd6e6 slide/slide.html --- a/slide/slide.html Fri May 27 10:15:16 2022 +0900 +++ b/slide/slide.html Thu Apr 13 11:18:26 2023 +0900 @@ -78,7 +78,7 @@
Mizuki Kiyama - - profile not found - + - Shinji Kono 琉球大学 -
@@ -119,8 +119,8 @@
  • 学内ネットワークや、貸出用の仮想マシン (Virutal Machine: VM) など、授業や研究を円滑に進める為のサービスを、24時間365日提供している
  • 学科システムはシステム管理チームによって管理されている
  • @@ -156,13 +156,13 @@

    学科システムのトラブルの例

      -
    1. クラウドサーバーのHDDが物理故障していた為アクセス不可 (8/2)
    2. -
    3. サーバー交換により復旧 (8/6)
    4. -
    5. 計画停電によりオンプレサーバーが故障 (8/10)
    6. -
    7. 復旧時にファームウェアアップデートによりKVMのIPv4が停止 (8/17)
    8. +
    9. クラウドサーバーのHDDが物理故障していた為アクセス不可 (2021/8/2)
    10. +
    11. サーバー交換により復旧 (2021/8/6)
    12. +
    13. 計画停電によりオンプレサーバーが故障 (2021/8/10)
    14. +
    15. 復旧時にファームウェアアップデートによりKVMのIPv4が停止 (2021/8/17)
    -

    1.はHDD故障アラームを処理していれば防げた可能性がある

    +

    1.はHDD故障アラームを処理していれば早期に対応できた可能性がある

    @@ -178,7 +178,7 @@
  • 新しいバージョンのGitlabを導入しアカウントを移行することで復旧
  • -

    Gitlabのログを監視していれば防げた可能性がある

    +

    Gitlabのログを監視していれば対応できた

    @@ -288,7 +288,8 @@

    監視システム(サービス監視)

    -

    grafanaでダッシュボードを用いて可視化

    +

    grafanaでダッシュボードを用いて可視化
    +nginxの例 サービスの状態、処理された接続の総数、接続の状態

    @@ -311,7 +312,8 @@

    監視システム(ログ収集)

    -

    grafanaのダッシュボードを用いて可視化 +

    grafanaのダッシュボードを用いて可視化
    +sshの例 ログの総数、エラーの総数、単位時間ごとのログ出力の数

    @@ -334,7 +336,7 @@

    監視システム(アラート送信)

    Mattermostに送信されるアラートは以下のような形式

    -

    +

    @@ -366,7 +368,7 @@ - /alert add $name $label $pattern $time + /alert add NAME LABEL PATTERN TIME アラートルールの追加 @@ -374,7 +376,7 @@   - /alert list all $name + /alert list ALL NAME アラートルールの表示 @@ -382,7 +384,7 @@   - /alert delete $name + /alert delete NAME アラートルールの削除 @@ -434,10 +436,16 @@
    • 外部公開されているシステムの攻撃を検知する事が可能だと考える
        -
      • 外部公開されているシステムの脆弱性をついた攻撃はPODTメソッドで行われる事が多い事から、一定時間に大量のPOSTがあった際に検知するよう設定することで攻撃を事前に防げる
      • +
      • 外部公開されているシステムの脆弱性をついた攻撃はPOSTメソッドで行われる事が多い
      • +
      • 一定時間に大量のPOSTがあった際に検知するよう設定することで攻撃を事前に防げる
    • -
    • 誤ったアラートルールを設定してしまい必要以上にアラートが発生する場合にはdeleteコマンドを使うことでMattermostからすぐに削除することができる
    • +
    • 誤ったアラートルールを設定した場合 +
        +
      • 必要以上にアラートが発生する
      • +
      • deleteコマンドでMattermostからすぐに削除することができる
      • +
      +
    @@ -464,7 +472,7 @@
  • 収集したデータのバックアップや提案環境の構築場所を運用にするに当たって改善する必要がある
  • 本研究では監視対象を限定したので稼働しているサービスすべてを監視する必要がある
  • 現在はオンプレ環境でのみ動作している為クラウドにセカンダリを構築し冗長化する必要がある
  • -
  • このアラートルール設定では管理者の技量に左右されてしまう為必要なアラートの選択
  • +
  • このアートルール設定では管理者の技量に左右されてしまう為改善する必要がある
  • チャットツールでは過去に遡っての確認が難しい為Gitlab Scrapboxとの連携する必要がある
  • diff -r c8ffd012e8ab -r 02066b6bd6e6 slide/slide.md --- a/slide/slide.md Fri May 27 10:15:16 2022 +0900 +++ b/slide/slide.md Thu Apr 13 11:18:26 2023 +0900 @@ -17,8 +17,8 @@ * 学科システムは約300人の学生と教員に対して様々なサービスを提供している * 学内ネットワークや、貸出用の仮想マシン (Virutal Machine: VM) など、授業や研究を円滑に進める為のサービスを、24時間365日提供している * 学科システムはシステム管理チームによって管理されている - * 有志の職員と学生を中心に結成されている. - * 教師1名、職員2名、学生数名 + * 有志の職員と学生を中心に構成されている. + * 教師1名、職員2名、学生11名 # 安定した運用の為の構築 * 一般的にシステムを保守・運用する上で障害は必ず発生する @@ -30,13 +30,13 @@ * これらの情報を可視化する(Grafana) # 学科システムのトラブルの例 -1. クラウドサーバーのHDDが物理故障していた為アクセス不可 (8/2) -2. サーバー交換により復旧 (8/6) -3. 計画停電によりオンプレサーバーが故障 (8/10) -4. 復旧時にファームウェアアップデートによりKVMのIPv4が停止 (8/17) +1. クラウドサーバーのHDDが物理故障していた為アクセス不可 (2021/8/2) +2. サーバー交換により復旧 (2021/8/6) +3. 計画停電によりオンプレサーバーが故障 (2021/8/10) +4. 復旧時にファームウェアアップデートによりKVMのIPv4が停止 (2021/8/17) -1.はHDD故障アラームを処理していれば防げた可能性がある +1.はHDD故障アラームを処理していれば早期に対応できた可能性がある # Gitlabトラブルの対処 * Gitlabの自動アップデートはメジャーアップデートに対応してなかった @@ -45,7 +45,7 @@ * 新しいバージョンのGitlabを導入しアカウントを移行することで復旧 -Gitlabのログを監視していれば防げた可能性がある +Gitlabのログを監視していれば対応できた # 監視システムでの問題 * アラート送信の機能は運用する中で過不足が無いように調整が必要 @@ -86,7 +86,8 @@ # 監視システム(サービス監視) -grafanaでダッシュボードを用いて可視化 +grafanaでダッシュボードを用いて可視化 +nginxの例 サービスの状態、処理された接続の総数、接続の状態 @@ -97,7 +98,8 @@ # 監視システム(ログ収集) -grafanaのダッシュボードを用いて可視化 +grafanaのダッシュボードを用いて可視化 +sshの例 ログの総数、エラーの総数、単位時間ごとのログ出力の数 # 監視システム(アラート送信) @@ -109,7 +111,7 @@ # 監視システム(アラート送信) Mattermostに送信されるアラートは以下のような形式 - + # Mattermostでのアラートルール編集 @@ -126,11 +128,11 @@ | コマンド | 機能 | | ---- | ---- | -| /alert add $name $label $pattern $time | アラートルールの追加 | +| /alert add NAME LABEL PATTERN TIME | アラートルールの追加 | ||| -| /alert list all $name | アラートルールの表示 | +| /alert list ALL NAME | アラートルールの表示 | ||| -| /alert delete $name | アラートルールの削除 | +| /alert delete NAME | アラートルールの削除 | # Mattermostでのアラートルール編集 @@ -155,9 +157,12 @@ # 設定例 * 外部公開されているシステムの攻撃を検知する事が可能だと考える - * 外部公開されているシステムの脆弱性をついた攻撃はPODTメソッドで行われる事が多い事から、一定時間に大量のPOSTがあった際に検知するよう設定することで攻撃を事前に防げる + * 外部公開されているシステムの脆弱性をついた攻撃はPOSTメソッドで行われる事が多い + * 一定時間に大量のPOSTがあった際に検知するよう設定することで攻撃を事前に防げる -* 誤ったアラートルールを設定してしまい必要以上にアラートが発生する場合にはdeleteコマンドを使うことでMattermostからすぐに削除することができる +* 誤ったアラートルールを設定した場合 + * 必要以上にアラートが発生する + * deleteコマンドでMattermostからすぐに削除することができる # まとめ * 障害対応のための監視システムを提案した @@ -168,5 +173,5 @@ * 収集したデータのバックアップや提案環境の構築場所を運用にするに当たって改善する必要がある * 本研究では監視対象を限定したので稼働しているサービスすべてを監視する必要がある * 現在はオンプレ環境でのみ動作している為クラウドにセカンダリを構築し冗長化する必要がある -* このアラートルール設定では管理者の技量に左右されてしまう為必要なアラートの選択 +* このアートルール設定では管理者の技量に左右されてしまう為改善する必要がある * チャットツールでは過去に遡っての確認が難しい為Gitlab Scrapboxとの連携する必要がある \ No newline at end of file diff -r c8ffd012e8ab -r 02066b6bd6e6 slide/slide.pdf.html --- a/slide/slide.pdf.html Fri May 27 10:15:16 2022 +0900 +++ b/slide/slide.pdf.html Thu Apr 13 11:18:26 2023 +0900 @@ -103,8 +103,8 @@
  • 学内ネットワークや、貸出用の仮想マシン (Virutal Machine: VM) など、授業や研究を円滑に進める為のサービスを、24時間365日提供している
  • 学科システムはシステム管理チームによって管理されている
      -
    • 有志の職員と学生を中心に結成されている.
    • -
    • 教師1名、職員2名、学生数名
    • +
    • 有志の職員と学生を中心に構成されている.
    • +
    • 教師1名、職員2名、学生11名
  • @@ -140,13 +140,13 @@

    学科システムのトラブルの例

      -
    1. クラウドサーバーのHDDが物理故障していた為アクセス不可 (8/2)
    2. -
    3. サーバー交換により復旧 (8/6)
    4. -
    5. 計画停電によりオンプレサーバーが故障 (8/10)
    6. -
    7. 復旧時にファームウェアアップデートによりKVMのIPv4が停止 (8/17)
    8. +
    9. クラウドサーバーのHDDが物理故障していた為アクセス不可 (2021/8/2)
    10. +
    11. サーバー交換により復旧 (2021/8/6)
    12. +
    13. 計画停電によりオンプレサーバーが故障 (2021/8/10)
    14. +
    15. 復旧時にファームウェアアップデートによりKVMのIPv4が停止 (2021/8/17)
    -

    1.はHDD故障アラームを処理していれば防げた可能性がある

    +

    1.はHDD故障アラームを処理していれば早期に対応できた可能性がある

    @@ -162,7 +162,7 @@
  • 新しいバージョンのGitlabを導入しアカウントを移行することで復旧
  • -

    Gitlabのログを監視していれば防げた可能性がある

    +

    Gitlabのログを監視していれば対応できた

    @@ -272,7 +272,8 @@

    監視システム(サービス監視)

    -

    grafanaでダッシュボードを用いて可視化

    +

    grafanaでダッシュボードを用いて可視化
    +nginxの例 サービスの状態、処理された接続の総数、接続の状態

    @@ -295,7 +296,8 @@

    監視システム(ログ収集)

    -

    grafanaのダッシュボードを用いて可視化 +

    grafanaのダッシュボードを用いて可視化
    +sshの例 ログの総数、エラーの総数、単位時間ごとのログ出力の数

    @@ -318,7 +320,7 @@

    監視システム(アラート送信)

    Mattermostに送信されるアラートは以下のような形式

    -

    +

    @@ -350,7 +352,7 @@ - /alert add $name $label $pattern $time + /alert add NAME LABEL PATTERN TIME アラートルールの追加 @@ -358,7 +360,7 @@   - /alert list all $name + /alert list ALL NAME アラートルールの表示 @@ -366,7 +368,7 @@   - /alert delete $name + /alert delete NAME アラートルールの削除 @@ -418,10 +420,16 @@
    • 外部公開されているシステムの攻撃を検知する事が可能だと考える
        -
      • 外部公開されているシステムの脆弱性をついた攻撃はPODTメソッドで行われる事が多い事から、一定時間に大量のPOSTがあった際に検知するよう設定することで攻撃を事前に防げる
      • +
      • 外部公開されているシステムの脆弱性をついた攻撃はPOSTメソッドで行われる事が多い
      • +
      • 一定時間に大量のPOSTがあった際に検知するよう設定することで攻撃を事前に防げる
    • -
    • 誤ったアラートルールを設定してしまい必要以上にアラートが発生する場合にはdeleteコマンドを使うことでMattermostからすぐに削除することができる
    • +
    • 誤ったアラートルールを設定した場合 +
        +
      • 必要以上にアラートが発生する
      • +
      • deleteコマンドでMattermostからすぐに削除することができる
      • +
      +
    @@ -448,7 +456,7 @@
  • 収集したデータのバックアップや提案環境の構築場所を運用にするに当たって改善する必要がある
  • 本研究では監視対象を限定したので稼働しているサービスすべてを監視する必要がある
  • 現在はオンプレ環境でのみ動作している為クラウドにセカンダリを構築し冗長化する必要がある
  • -
  • このアラートルール設定では管理者の技量に左右されてしまう為必要なアラートの選択
  • +
  • このアートルール設定では管理者の技量に左右されてしまう為改善する必要がある
  • チャットツールでは過去に遡っての確認が難しい為Gitlab Scrapboxとの連携する必要がある