• 戻る（クラウド）
  • メガクラウドサービス
  • クラウド利用時の注意事項

クラウド利用時の注意事項をまとめる。

様々なクラウドリソースのアクセス制御

• NW 経路制御
• VM 管理権限制御
• Storage アクセス制御

補足（この 3 つが「多層防御」を構成する）: 一見バラバラに見えるが、
同じリソースに対する 3 つの独立した関門である。

【攻撃者から見た到達経路】
  ① そもそも到達できるか？        → NW 経路制御（NSG / Private Link）
  ② 管理操作を実行できるか？      → VM 管理権限制御（RBAC）
  ③ データを読み書きできるか？    → Storage アクセス制御（SAS / RBAC / FW）

重要なのは、どれか 1 つでも守られていれば侵害されないという点で、
逆に言えば1 つに頼ってはいけないということでもある。

層	Azure での手段
NW 経路	Network Security Group (NSG)、Azure Private Link、Azureのプロキシ的なモノ。
管理権限	RBAC、Azureのアクセス制御と権限
データ	ストレージ ファイアウォール、SAS、マネージド ID（Azure Key Vault）

よくある失敗は、**「閉域にしたから権限は緩くてよい」**という判断で、
これは①だけに頼っている状態である。
内部からの操作ミスや、侵害された踏み台からの攻撃には無力になる。

• 認証情報
• 認証システム

補足（クラウドで最も狙われるのは認証情報）: クラウドでは
管理コンソール（ARM API）がインターネットに公開されているため、
資格情報が漏れた時点で、経路制御は無意味になる
（攻撃者は正規の API 経由で操作できる）。

したがって、次の 3 点が要点になる。

対策	内容
資格情報を「置かない」	マネージド ID を使い、接続文字列やキーをコードや設定に持たない
多要素認証（MFA）	管理操作には必須（AzureのPoC環境を契約する）
特権の常時付与を避ける	PIM（Privileged Identity Management）で必要な時だけ昇格

特に 1 つ目が本質的で、
Web/APの分離で述べた
「鍵を盗まれないようにする」から「そもそも鍵を置かない」へという
転換がここでも当てはまる。

また、ソースコードへの資格情報の混入（GitHub への誤コミット）は
実際に多発しており、自動スキャンで検出される仕組み
（GitHub Secret Scanning、Defender for Cloud）を
有効にしておくべきである。

• アクセス制御
• データ暗号化

補足（暗号化は「何から守るか」で選ぶ）: 「データ暗号化」と
一括りにされるが、守れる対象が層ごとに異なる
（Azureの仮想マシンの補足も参照）。

層	守れるもの	守れないもの
保存時（SSE、TDE）	物理ディスクの盗難・廃棄	正規の権限を持つ者
転送時（TLS）	経路上の盗聴	両端
アプリケーション層（Always Encrypted 等）	DB 管理者からも見えない	アプリ自身
使用中（Confidential Computing）	ホスト／基盤事業者から	－

Azure ではストレージも DB も既定で暗号化されているため、
「暗号化していない」という状態は原則として存在しない。
追加の暗号化を検討すべきなのは、

• 規制要件で顧客管理キー（CMK）が求められる、
• DB 管理者にも見せたくない列がある（マイナンバー等）

といった具体的な理由がある場合に限られる。

特に、経済的損失を狙ったものには注意が必要。

補足（「経済的損失を狙ったもの」の具体例）: この一行は
クラウド特有の攻撃を指しており、重要な指摘である。
オンプレミスには無い性質として、
リソースが従量課金であるため、攻撃が直接的に金銭被害になる。

攻撃	内容
クリプトジャッキング	侵害したサブスクリプションで暗号通貨をマイニング。高性能 VM を大量に起動され、数日で数百万円の請求
経済的 DoS（EDoS）	大量アクセスで自動スケールを暴走させ、課金を膨らませる
下り転送の悪用	大容量データを繰り返しダウンロードさせ、egress 課金を発生させる
ストレージへの大量書き込み	トランザクション課金の消費

対策としては、

手段	内容
予算アラート	ただし通知するだけで止まらない（AzureのPoC環境を契約する）
クォータの制限	vCPU 上限を必要最小限に（Azureのクォータ）
Azure Policy	高価な SKU の作成自体を禁止
自動スケールの上限設定	際限なく増えないようにする
Defender for Cloud	異常なリソース作成を検知

特に クォータと Policy による「作れないようにする」 が効く。
検知や通知は事後であり、課金は既に発生しているためである。

アウトバウンドを絞る必要性は低いが、
セキュリティが重要になる環境では、
フールプルーフ的な意味でアウトバウンドも絞る。

補足（現在はこの判断が逆転している）: 「アウトバウンドを絞る
必要性は低い」という記述は執筆当時の一般的な認識だが、
**現在の考え方は「絞るのが原則」**に変わっている。

理由は、侵害を前提とする（ゼロ トラスト）という発想の普及にある。

【従来の発想】 入り口を守れば中は安全 → アウトバウンドは自由でよい
【現在の発想】 侵害されることを前提 → 侵害後の被害を最小化する
                 ↓
               アウトバウンドの制限＝
                 ・データを外に持ち出させない
                 ・C2 サーバに繋がせない

詳細はAzureのアウトバウンド設計、
Azureのプロキシ的なモノ。に整理してある。
Network Security Group (NSG)で述べたとおり
既定はアウトバウンド全開であるため、
何もしなければ制限されていない点に注意が要る。

ただし、本文の「必要性は低い」という判断にも根拠はある。
アウトバウンドを絞ると運用負荷が上がる（パッケージ取得、
更新プログラム、ライセンス認証などが軒並み通らなくなる）ためで、
要件と運用体制に応じて段階的に絞るのが現実的である。

• 不用意に開けない。ウィルス感染する。
• 開ける場合は、以下に注意する。

• 製品
  • 製品に脆弱性があったらアウト。
  • 製品開発元に問い合わせて、脆弱性をチェックするなどする。
• OSS
  • OSS に脆弱性があったらアウト。
  • 情報を収集して、当該バージョンの脆弱性をチェックするなどする。
• 自作プログラム
  • 自作プログラムに脆弱性があったらアウト。
  • 自作プログラムに脆弱性診断を施す必要がある。

補足（3 分類は「誰が脆弱性を見つけて直すか」の違い）: この分類の
実務的な意味は、責任の所在と対応の速さにある。

種類	脆弱性を見つけるのは	修正を作るのは	情報の入手
製品	ベンダ	ベンダ（待つしかない）	サポート契約、通知
OSS	コミュニティ	コミュニティ（自分で当てる）	CVE、GitHub Advisory
自作	自分	自分	診断しない限り分からない

下に行くほど自分の責任が重くなる。
特に自作プログラムは、誰も教えてくれないという点が決定的で、
だからこそ本文は「脆弱性診断を施す必要がある」としている
（Webアプリケーション脆弱性対策、
脆弱性対策のポイント）。

なお、現在は依存ライブラリの脆弱性（サプライ チェーン）が
大きな比重を占める。自作プログラムであっても、
中身の大半は OSS のライブラリであるためで、

手段	内容
SCA（ソフトウェア構成分析）	Dependabot、dotnet list package --vulnerable
SBOM	使っている部品の一覧を管理する
コンテナ イメージのスキャン	Defender for Containers、Trivy

といった仕組みを CI に組み込むのが標準的になっている
（CI/CD パイプライン）。

• 前述の製品（Windows の RDP）、OSS（Linux の SSH）のエンドポイントに該当する。
• SSH や RDP のインバウンド・ポートを開けた場合、
  ガードがパスワードのみになるため、パスワードの強度が問題になる。

移行メモ（体裁）: 原典の「パスワードに強度が注意になる」は
文意から「パスワードの強度が問題になる」と読めるため整えた。

補足（この指摘は現在も最重要）: Azure の IP レンジは
常時スキャンされており、3389 / 22 を開けると
数分〜数時間で総当たり攻撃が始まる。

対策の優先順位は次のとおり。

優先	手段
1	そもそも開けない（Azure Bastion、リモート デスクトップ ゲートウェイ）
2	Just-in-Time VM アクセス（必要な時だけ開ける）
3	送信元 IP を限定（NSG）
4	鍵認証のみにする（パスワード認証を無効化。OpenSSH）

本文が「ガードがパスワードのみになる」と書いているのは
パスワード認証を使っている場合の話で、
公開鍵認証にすれば総当たりは事実上不可能になる。
Azureの評価環境を入手するの構成例でも
Linux 側は「認証の種類: SSH 公開キー」を選んでいる。

上記で不安がある場合は、クライアント － サーバ間を VPN でガードする。

クラウド上であるため、

下記データは基本的に保存しない。

• 個人情報
• 機密情報
• 輸出不可の情報

下記データは基本的にアップロードしない。

• 個人情報
• 機密情報
• 輸出不可の情報

補足（この方針の位置付け）: 本節の記述は
PoC・検証環境を前提とした方針として読むのが適切である
（Azureによる基盤開発法の
3 環境マトリックスで「PoC 環境：本番やテストのデータは持ち込み不可」と
されているのと同じ考え方）。

本番環境で「クラウドには個人情報を置かない」という判断は、
現在では一般的ではない。金融機関や官公庁を含め、
適切な統制のもとでクラウドに機密データを置く運用が定着している。

本番で機密データを扱う場合の要点は次のとおり。

観点	内容
データの所在（リージョン）	日本国内に限定する（データ主権）
暗号化	保存時・転送時。必要なら顧客管理キー（CMK）
アクセスの最小化	RBAC、Private Endpoint、監査ログ
認定・監査	ISMAP、SOC2、ISO 27001 等の準拠状況
輸出管理	技術情報の越境移転（外為法）。リージョン選択と運用者の所在が論点

特に「輸出不可の情報」については、
データが日本国内に保存されていても、
海外の運用者がアクセスできる状態なら「輸出」に当たり得るという
論点があり、契約と技術の両面での確認が必要になる。

つまり、「置かない」という単純な方針から、
「どういう条件なら置いてよいか」を定義する方向へ、
現在の実務は移っている。

• 主要なメガクラでは、

  • ポータルの操作を権限で制御
  • VM の通信を src-dst で制御

  などが可能。

• 詳しくは、「Azure Subscriptionの管理@エンプラ」を参照。

補足（「クラウド機能を使用して管理する」が方針として重要）: 一行だが、
オンプレの管理手法をそのまま持ち込まないという指針である。

やりたいこと	オンプレ的な発想	クラウドの機能
操作を制限する	手順書、申請フロー	RBAC、Azure Policy（そもそも実行できなくする）
構成を守る	台帳、定期点検	Policy、リソース ロック（変更を拒否する）
変更を追う	作業報告書	アクティビティ ログ（自動的に全部残る）
通信を制御する	機器の設定	NSG、UDR（API で宣言的に）

要点は、「人が守るルール」から「システムが強制する制約」へという
転換である。

特に Azure Policy は、

• 高価な SKU を作らせない、
• タグの付与を必須にする、
• パブリック IP の作成を禁止する、
• 診断設定を自動で付与する（DeployIfNotExists）

といった制御をサブスクリプション全体に強制でき、
手順書やレビューよりはるかに確実である
（Azureのアクセス制御と権限、
Azureによる基盤開発法）。

---

Tags: 移行, インフラストラクチャ, クラウド