ドワンゴが運営する動画配信サービス「ニコニコ」で発生している大規模障害について、ニコニコの栗田代表がX（旧Twitter）で状況を報告した。障害の原因はサイバー攻撃だとしており、「少なくともこの週末中での復旧は困難な状況です」と明かした。
⇧ 各システムの関連が分からないのですが、サイバー攻撃された原因と対応策を公開してくれるとありがたいですね。
とりあえず、
⇧「独立行政法人情報処理推進機構（IPA：Information-technology Promotion Agency, Japan）」が公開している対策以外が必要だったのかどうかとか知りたいですな。
まぁ、上記の情報セキュリティ対策をしていた上で、サイバー攻撃されたというのであれば、アプリケーション側では対策の仕様が無い気はしますが...
ちなみに、
⇧ 上記サイト様によりますと、知っておきたいサイバー攻撃だけでも39種類もあるらしい...
サイバー犯罪が増加し続ける現代社会において、
ゼロトラスト・セキュリティモデル（英: zero trust security model）は、ITシステムの設計及び実装に関するモデルである。ゼロトラスト・アーキテクチャ（zero trust architecture、ZTA）とも呼ばれる。
ゼロトラスト・セキュリティモデルは「決して信用せず、常に検証せよ」という考えに基づいている。これは、たとえ社内LANなど許可されたネットワークに接続されていた場合や、事前に検証されていた場合でも、信用しない。
⇧ の『決して信用せず、常に検証せよ』とあるように、セキュリティのコストが嵩むのは致し方ないということですかね。
Azure Blob Storageで同じファイル名のファイルをどう管理すべきか
Azure Blob Storage サービスにも「バージョン管理」の機能があるようで、
BLOB のバージョン管理
Blob Storage のバージョン管理を有効にし、以前のバージョンのオブジェクトを自動的に維持することができます。 BLOB のバージョン管理が有効になっている場合は、以前のバージョンの BLOB にアクセスし、変更または削除されたデータを復旧することができます。
https://learn.microsoft.com/ja-jp/azure/storage/blobs/versioning-overview
推奨されるデータ保護の構成
BLOB のバージョン管理は、BLOB データの包括的なデータ保護戦略の一部です。 BLOB データの最適な保護のために、Microsoft では次のデータ保護機能をすべて有効にすることをお勧めしています。
https://learn.microsoft.com/ja-jp/azure/storage/blobs/versioning-overview
- BLOB のバージョン管理。以前のバージョンの BLOB が自動的に維持されます。 BLOB のバージョン管理が有効になっている場合は、以前のバージョンの BLOB を復元し、データが誤って変更または削除された場合に復旧することができます。 BLOB のバージョン管理を有効にする方法については、「BLOB のバージョン管理を有効にして管理する」をご覧ください。
- コンテナーの論理的な削除。削除されたコンテナーを復元します。 コンテナーの論理的な削除を有効にする方法については、「コンテナーの論理的な削除を有効にして管理する」をご覧ください。
- BLOB の論理的な削除。削除された BLOB、スナップショット、またはバージョンを復元します。 BLOB の論理的な削除も有効にする方法については、BLOB の論理的な削除の有効化と管理に関する記事をご覧ください。
データ保護に関する Microsoft の推奨事項の詳細については、「データ保護の概要」を参照してください。
https://learn.microsoft.com/ja-jp/azure/storage/blobs/versioning-overview
⇧ Microsoftとしては、「バージョン管理」を「有効」にすることを推奨していると。
ただし、「バージョン管理」を有効にすると、
注意事項
ストレージ アカウントの BLOB のバージョン管理を有効にすると、そのアカウント内の BLOB に対するすべての書き込み操作で新しいバージョンが作成されます。 このため、BLOB のバージョン管理を有効にすると、追加のコストが発生する可能性があります。 コストを最小限に抑えるには、ライフサイクル管理ポリシーを使用して、古いバージョンを自動的に削除します。 ライフサイクル管理の詳細については、「Azure Blob Storage アクセス層の自動化によるコストの最適化」を参照してください。
https://learn.microsoft.com/ja-jp/azure/storage/blobs/versioning-overview
⇧ コストが増加しますと。
「バージョン管理」が「無効」の場合、
BLOB のバージョン管理を有効または無効にする
バージョン管理を無効にした後は、現在のバージョンを変更すると、バージョンではない BLOB が作成されます。 BLOB に対する以降のすべての更新では、前の状態を保存せずにデータが上書きされます。 既存のすべてのバージョンは、以前のバージョンとして保持されます。
https://learn.microsoft.com/ja-jp/azure/storage/blobs/versioning-overview
⇧ 上書きされるっぽい。
つまり、Azure Blob Storage上に「ファイルA」というファイル名のファイルがアップロードされていた状態で、同じファイル名のファイルがAzure Blob Storageにアップロードされた場合、
■「バージョン管理」が「有効」の場合
- ファイルA（バージョン1）
- ファイルA（バージョン2）
■「バージョン管理」が「無効」の場合
- ファイルA（バージョン1）
という感じで、Azure Blob Storage サービスの「データ保護機能」の内の「バージョン管理」が「有効」か「無効」かで挙動が異なってくると。
同じファイル名のファイルを別のものとして管理したい要件において、Azure Blob Storage サービスの「バージョン管理」の機能が「無効」の場合は、何かしらの対応をアプリケーション側で検討する必要があると。
と言っても、
Blob Storage のリソース
Blob Storage には、3 種類のリソースがあります。
- ストレージ アカウント
- ストレージ アカウント内のコンテナー
- コンテナー内の BLOB
次の図に、これらのリソースの関係を示します。
https://learn.microsoft.com/ja-jp/azure/storage/blobs/storage-blobs-introduction
⇧ Azure Blob Storage は、上図のような構成でファイルを管理しているようなのですが、
⇧「コンテナー」の部分でサブディレクトリのような入れ子構造を実現できないので、「BLOB」の方で管理するファイルの命名で疑似的にサブディレクトリ構造を実現するぐらいしか対策の仕様がない。
なので、
- https://[myaccount].blob.core.windows.net/[mycontainer]/[version_1]/[ファイルA.csv]
- https://[myaccount].blob.core.windows.net/[mycontainer]/[version_2]/[ファイルA.csv]
みたいな感じで、「BLOB名」でバージョンが区別できるようにしてあげる必要があると。
まぁ、
- https://[myaccount].blob.core.windows.net/[mycontainer]/[1]/[ファイルA.csv]
- https://[myaccount].blob.core.windows.net/[mycontainer]/[2]/[ファイルA.csv]
単純に連番で疑似的な階層を表現する感じになるんかな。
このあたりは、プロジェクトによって変わってくると思うのと、インフラ側の話になりそうな気がしますが、
- Azure Blob Storage サービスの「バージョン管理」の機能が「有効」
- Azure Blob Storage サービスの「バージョン管理」の機能が「無効」
のどちらにしているのかを、Azure Blob Storage サービスの設定周りについて把握しているメンバーに確認する必要がありますな。
Azure Portal上（GUI環境）からもAzure Blob Storage へファイルのアップロードやダウンロードができそうですが、
⇧ Microsoftのドキュメントだと、疑似的なサブディレクトリ構成でアップロードする例が記載されていないのだけど、
⇧ stackoverflowによると、「Upload to folder」の部分で、『スラッシュ（「/」）』区切りで実現したいディレクトリ階層の文字列を指定すれば良いらしい。
実際に、Azure Portal上で「Azure Blob Storage」のサービスで「ストレージ ブラウザー」から「アップロード」を選択すると、
⇧ 上図のように「アップロード先のフォルダー」が指定できるようになっている。
何と言うか、Microsoftのドキュメント、相変わらず整理されてない、と言うか、情報が足りて無さ過ぎるんよな...
公開しているサービスに対してのドキュメントとは思えない...
Microsoft社内でしか利用していないドキュメントであるならば、文句は無いんだけど、一般に公開しているドキュメントで不明瞭な部分が多過ぎるのは残念過ぎるんだが...
サービスを利用する側は、エスパーじゃないから、ドキュメントに記載の無い内容を把握できないし、忖度して推測せざるを得ないとすると認識齟齬が発生し得るからして、ドキュメントの整備を御座なりにしないで欲しいのよね...
大企業だから許されると思っているのかも知らんけど、誠実さの欠片も無い対応が目立ちますな...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
