こんにちは。この記事では、Azure App Serviceで登場するSandboxという概念をおさらいしておこうと思います。
本日の教科書はこちらです。この概念についてはKuduのオフィシャルなWikiの中で紹介されています。こうした概念があることを理解しておけば、App Serviceでできることとできないことを理解することにも役立つのではないかと思います。
Azure Web App sandbox
https://github.com/projectkudu/kudu/wiki/Azure-Web-App-sandbox
今回はこちらを読んでわかったことを箇条書きでまとめておきます。
それではまいります。
Contents
SandBoxとは?
- Azure Functionsを含めたApp Serviceが実行されるセキュアな環境。「App ServiceはSandbox上で動作している」といえる
- App Serviceはマルチテナントモデルなので1つの物理マシン上に複数ユーザのアプリが稼働する前提の設計になっている
- 各アプリはそれぞれ個別のSandbox環境で実行されることで、セキュリティの担保や同じ物理マシン上で実行される他のアプリ動作とのリソース競合、それによるリソース枯渇等の回避を実現している
SandBoxの動作
- App Service では、IISのw3wp.exeプロセスをルートに、利用するランタイムに応じた子プロセス(PHPであればphp-cgi.exe、Node.jsであればnode.exeなど)が生成されて動作しているが、Sandboxではこれらをひとつのグループとみなしてリソースの割り当てを行うことでリソース制限を行っている。
- なので、子プロセスを増やせば利用可能なリソースが増える、ということはない。
SandBoxの制約
思ったよりも長い制約のリストだったので、部分だけ列挙します。
一覧は以下を参照ください。
https://github.com/projectkudu/kudu/wiki/Azure-Web-App-sandbox#app-service-plans-and-sandbox-limits
- 基本的な考え方として、Windowsの共有コンポーネントへのアクセスは極力制限する方向
- なので、レジストリへの書き込みはいかなる状況においても許可されていない(読み取りと列挙は問題ない)
- イベントログへの書き込み・読み取りも許可されていない。代わりに仮想化イベントログが利用可能
- シンボリックの作成はできない。既存のシンボリックを利用することはできる
- インターネットからのアプリケーションへのアクセスには、80と443ポートしか利用できない。SandBox内からの接続をリッスンするソケットの作成は可能(ただし、Sandbox外からのアクセスはできない)。
- ローカルアドレス(localhost, 127.0.0.1)やマシン自身のIPへの接続試行は特定の状況を除いて許可されていない
- アプリケーションから、ポート445、137、138、139を使用した接続は許可されていない(これはなんでだ・・?)
- アプリケーションがRow Socketを生成することはできない。なので、App ServiceからSYN攻撃などはできない
- 一連のSandboxの制限により、以下のフレームワークは利用できないことが分かっている
- 一部のPDF Generator(Syncfusion, Siberix, Spire.PDF)
- PhantomJS/Selenium(ローカルアドレスやGDI+を利用するため)
- なお、価格プラン毎にSandboxによる制約も多少の違いはある
以上、簡単ではありますがSandboxという概念についての簡単なまとめでした。勉強になりました。
少しでも参考になりましたら幸いです。
おしまい
コメントを残す