私がサーバレスに全面移行した理由はセキュリティです。セキュリティパッチも当てず放置してしまっていました。
本記事は「サーバを一度構築したら、正常にレスポンスがあるうちは放置する」ような運用をしている方に向けた記事です。
私は学生時代に、「パーツあげるからサーバつくって運用してみなよ！！」と仲のよかった教授がいってくれたことでサーバ構築をはじめました。CentOS入れて、Apache入れて、よくわからないけどiptablesをoffにしたらすごい公開できた！！という体験はとてもよかったです。
その後、アプリをつくるようになって、レンタルサーバではスペックが足りなくなったので、お名前ドットコムでVPSを借りて、AWSが登場したら「すごい！構築したインスタンスをそのままスケールアップできる！！」と勢いのままEC2に移りました。Ansibleで構築自動化のレシピをつくって構築して、運用という名の 正常にレスポンス返してたら放置 。
いや、当時の自分に伝えたい。やめとけって。
結局、幸運なことにサーバレスに移行するまでに大きなトラブルなく、オリジナルでつくったインスタンスはすべて停止・終了しましたが、今から同じようなことしようという方（もしくはしてる方）に伝えておきます。間違っても受託でそれやっちゃだめ。
サーバ公開はリスクを伴う
サーバ公開って、単純にいうと、「あなたの管理するパソコンをインターネット経由で誰でもアクセスできるように公開」することなんですよね。もちろん、ポートを制限したり、パーミッションを絞ったり、権限を特定ディレクトリ以下でRead Onlyでしかアクセスできないようにと様々な制限はかけますが、そういう制限が不足してるサーバを狙って山のような不正アクセスがきます。
以下の実験記事がわかりやすい。
ポートを開放して2時間もするとさっそくBOTがかぎつけ、SSHサービスがオープンしていることを認識されました。不正なログインを何度も行ってきたことを確認でき、めでたく悪意のあるBOTに発見されたようですので、このままサーバを2週間ほど放置して経過を観察してみたいと思います。
https://business.ntt-east.co.jp/content/cloudsolution/column-try-04.html
ドメインに紐つけておらず、IPアドレスを告知してないサーバでも不正アクセスはきます。サービスに紐つけた場合は比較にならないほどきます（きます）。
で、「ちゃんと構築は手順書通りにつくった！」としても、様々なOSSを利用している以上、ライブラリにセキュリティホールがないと断言することはできません。情報処理推進機構のWebサイトをみると、どういった脆弱性が明らかになったかをみることができます。
もちろんこれをもって「こわいからサーバ公開なんてしちゃだめ」というつもりはありません。ただ、レシピ通りに構築して正常にレスポンスあるうちは放置したりすると万が一の場合に大変なことになります。どう大変かというと、
- 不正アクセスが成功した場合、Webサイトの改ざんは（嫌だけど）発覚するのでまし
- 踏み台にされて犯罪に利用された場合、気づけない
- 発覚した場合、警察はあなたのところにくる可能性が高い
- それが受託だった場合、普通に損害賠償請求がありえます
「システムベンダのセキュリティ対策義務 〜東京地裁平成25年1月23日判決を素材として〜」は取り扱ってる議題はSQLインジェクションですが、開発側の責任がとてもわかりやすくまとまってるのでぜひご一読ください。
サーバレスでスペシャリストのセキュリティを享受
もちろん、そういったリスクと向き合いながら「がんばる」という選択肢もありますが、私はサーバレスへの移行を行いました。サーバレスは何であるかはここでは割愛しますが、とても単純にいってしまうと、実行するコードは事前にサーバ自体ではなく、Cloud上のデータストレージにアップロードします。
AWS Lambdaでいうと、コード（関数）はS3にアップロードされます。Lambdaにはアップロードされません。そして、実行時にインスタンスが割り当てられ、その関数を実行し、終了するとインスタンスが解放されます。当然のことながら、不正ログインによって踏み台にされたり、ウイルスを埋め込んだりされることはありません（※デプロイした関数本体を除く）
AWS ElasticBeanstalkでいうと、Lambda同様コードはS3にアップロードされ、AWSによって構築された一連のパッケージにデプロイされます。EC2、ELBで構成されているためLambdaほど安全ではありませんが、ここを気にする場合、定期的に再起動することでクリーンなアーキテクチャを保持することができます。（Lambdaの定期実行と組み合わせることで、Dailyの再起動も可能： 参考）。
また、インスタンスにセキュリティパッチを自動で適用することができます。Elastic Beanstalk release notesをみるとわかりやすいのですが、月あたり2〜3の更新は行われています。
ちなみに責任共有モデルも目を通しておくといいです：
おわりに
繰り返しになりますが、本記事は私のように「サーバを一度構築したら、正常にレスポンスがあるうちは放置する」ような運用をしている方に向けた記事です。一昔前だと、そうはいっても選択肢がなかったため、小規模はレンタルサーバ、それを超えるとVPSなどで「自分でサーバ構築」が前提でしたが、現代ではサーバレスによって責務を分散するという手段がありますので、ぜひ活用を検討してもらえればと思います。
それではまた。
Discussion