意識の低いSRE SREに取り組む時の話

# 意識の低いSRE SREに取り組む時の話

## 前置き

![グラフ：目標レベル](https://qiita-image-store.s3.amazonaws.com/0/213982/b1b8e9a9-21d5-fe61-cccf-95a5376c644d.png)

|目標レベル|レベル0<br>技術負債山<br>(地盤沈下中)|レベル1<br>高尾山|レベル2　　　<br>富士山|レベル3　　　<br>エベレスト山|レベル4　　　<br>オリンポス山<br>(火星)|
|---|---|---|---|---|---|
|段階|オンプレで<br>LAMP構成|クラウド化|マイクロサービス化|パブリッククラウド<br>フル活用|世界中に<br>自社データセンターや<br>海底ケーブル|
|例|10年前に<br>作った<br>システムのまま|ここ数年で<br>作った<br>システム|2014年の<br>クックパッドの<br>報告が有名|Netflix,<br>Pokemon GO,<br>...|Amazon,<br>Microsoft,<br>Google,<br>facebook,<br>...|

レベル１のプロジェクトは、レベル４のプロジェクトとは違った物事の進め方になる、の話です。

オンプレでLAMP構成な人向けです。

## 本題

### １．あなたのプロジェクト用SREとは？

google社のSREそのまんまは、あなたのプロジェクトには向きません。  

なぜ？

google社の特長はこんな感じです。

* 予算超潤沢。
* スタッフ超優秀。
* 監視(集計)基盤整備済み。分析からスタート。

どうですか。この夢のような環境は。  

あなたのプロジェクトはきっとこんな感じです。

* 予算無い。
* スタッフ募集しても採用に至らない。
* 監視(集計)基盤整備からスタート。

google社のような規模感はあきらめて、もっと地に足のついた取り組みから始めましょう。


### ２．SRE==経費節減、ではない

「スタッフが足りないんですけどー」  
に対する改善案の筆頭は常に「採用しろ」です。

「CPUやメモリがいっぱいいっぱいなんですけどー」  
に対する改善案の筆頭は常に「増強しろ」です。

経費節減は、数ある目的の一つでしかなく、改善には費用の追加を伴うものが数多くあります。  
予算の手当のないSREの掛け声だけでは何も変えられませんよー


### ３．じゃあ何から手をつける？

まずセキュリティです。  
SRE以前の話として、セキュリティ不備はNGですよね。

#### 1 . セキュリティ：基本

セキュリティの基本は「多層防御」「各層で攻撃を緩和(0には出来ない)」です。  
パスワード認証してるからOK？  
それって１階層しか防御してないですよね。  
地道に対策を重ねて多層にしましょう。  

#### 2 . セキュリティ：ssh

sshは、「何でも出来る」強すぎる権限を持つことから、真っ先に攻撃されます。

* 2-1 . 対策１．ssh鍵認証にする。

    「デザイナーがuploadするからパスワード認証」が残ってませんか？  
    鍵認証に変更しちゃいましょう。すぐに。
    　

* 2-2 . 対策２．sshポートを変更する。

    22番ポート → 1022番ポート とかに変更し、22番ポートはクローズしましょう。  
    たったこれだけで、攻撃量が 1/100 以下に激減します。  
    やらない手はありません。  
    ただし、222番ポートとか2222番ポートは既に攻撃対象になってます。  
    もっと変な(予測しづらい)番号にしときましょう。
    　

* 2-3 . 対策３．IPアドレス制限する。

    事務所の固定IPアドレスからしかアクセスしない、ことがわかっている場合、IPアドレス制限をかけましょう。  
    IPアドレス制限は「最も硬い防御」の１つです。  
    かけられるなら、すかさずかけてしまいましょう。
    　


#### 3 . セキュリティ：http,https

webの脆弱性も狙われます。  
/phpmyadmin/ とか、/wp-admin/ とかですね。

* 3-1 . 対策１． 開発環境はhttpポート、httpsポートを変更する。

    無差別に狙われるのは、80番ポート、443番ポートの２つだけです。  
    開発サーバのポート番号は、80番ポート、443番ポートから変更しましょう。  
    これだけで、攻撃量 1/100 になります。
    　

* 3-2 . 対策２．IPアドレス制限する。

    事務所の固定IPアドレスからしかアクセスしない、ことがわかっている場合、IPアドレス制限をかけましょう。  
    IPアドレス制限は「最も硬い防御」の１つです。  
    かけられるなら、すかさずかけてしまいましょう。  
    /phpmyadmin/ とか、 /wp-admin/ とか。
    　

* 3-3 . 対策３． URLのディレクトリを１階層増やす。

    無差別に攻撃されるのは、/ 直下のURLです。  
    /phpmyadmin/ とか、 /wp-admin/ とか。  
    なので、

    * / → location /a/
    * /a/ → phpサーバ
    * /,/a/以外 → nginxで拒否

    のように１階層増やすと、phpサーバで受ける攻撃量が激減します。  
    多くのPHPフレームワークは、全URLを /index.php に吸い込む形になってるので、  
    攻撃発生 → 破られないまでも、多数アクセスによりphpサーバの性能激低下、  
    になる事が多いです。  
    これ、設計時にディレクトリ１個挟むだけでものすごく緩和できるのですが、  
    そうしてるサイトは見たことないです。  
    OPEN後に、こんなURL変更はほぼ無理なんで、設計時にここまで考えてURL設計しましょう。
    　


### ４．次に手をつけるのは？

ログ設定です。  

#### 1 . webサーバのログに、処理時間を追加する

webサーバのログ、デフォルトのcombinedには、処理時間入っていないですね。  
真っ先に入れましょう。  
どの画面が重いのか、計測を始めるのが先です。

#### 2 . webサーバのログを、MySQLとかに投入する

最終的には GCP bigquery にログ投入するのがよいのですが、そんなのは遠い将来の話です。  
fluentd で MySQL とかに投入しておきましょう。

#### 3 . 集計ツールを入れる

RedashかMetabase入れて、集計できるようにしましょう。

#### ４ . 集計する

あなたのプロジェクトのピーク時は何時から何時までですか？  
インターネット全体の傾向としては、21時-23時だそうですね。 https://it.srad.jp/story/17/02/20/0310205/

* ピーク時内の画面別処理時間合計が最大の画面
* ピーク時内の画面別アクセス数が最大の画面

の２つが２大巨頭です。  
この２つを集計ツールで見える化しましょう。

## 結論

SREに取り組む時、１にセキュリティ、２に監視(集計)基盤整備してくださいねー