クラウド・バックアップ

クラウド関連（特にバックアップ）

Azure SQL Databaseバックアップのヒント

バックアップ検証の自動化： 非本番環境へのリストアプロセスを自動化することで、バックアップを定期的にテストします。これにより、バックアップが有効であり、問題なくリストアできることを保証します。
イミュータブル・ストレージの活用： 重要なバックアップをイミュータブル・ストレージに保存することで、ランサムウェアから保護し、指定された保存期間内にバックアップを変更または削除できないようにします。
クロスサブスクリプション・バックアップの導入： セキュリティを強化するために、サブスクリプションレベルの問題や侵害から保護するために、バックアップのコピーを別のAzureサブスクリプションに保存することを検討します。
バックアップ操作にプライベートエンドポイントを使用する： プライベートエンドポイントを構成して、バックアップとリストア操作がパブリックインターネットではなく、安全なプライベート接続を介して行われるようにし、セキュリティを強化します。
バックアップデータの暗号化： 使用中のデータには透過的データ暗号化（TDE）を、保存されているバックアップデータには暗号化（at rest）を使用して、すべてのバックアップが暗号化されていることを確認し、セキュリティとコンプライアンスを強化します。

ユーザ・クラウドバックアップのランサムウェア対策ヒント

バックアップの暗号化を維持 データ保護を確実にし、ランサムウェアやサイバーセキュリティの問題によるリスクを軽減するために、暗号化されたリソースのクロスリージョンバックアップを作成します。
バックアップネットワークをセグメント化する： バックアップシステムをメインネットワークから分離します。専用のVLANを使用し、バックアップが運用システムと同じネットワークセグメントからアクセスできないように。
バックアップの完全性を定期的に検証する： バックアップの定期的なチェックと検証を行い、データが破損していないこと、必要なときに正常にリストアできることを確認します。
ローリングバックアップ戦略を採用する： ローリングバックアップスケジュールを実施し、複数のバージョンのデータを異なる時間枠で保持する。これにより、ランサムウェア感染前の時点に復元することができます。
エンドポイントプロテクションを使用してバックアップエージェントを保護する： バックアップ・エージェントを実行するすべてのデバイスとサーバーが、ランサムウェアのエントリ・ポイントにならないように、堅牢なエンドポイント保護機能を備えていることを確認します。

クラウドでのディザスタリカバリー・ヒント

クロスクラウド戦略の導入：複数のクラウドプロバイダーを活用することで、ベンダーロックインを回避し、異なるプラットフォームやインフラにリスクを分散することで耐障害性を高める。
フェイルオーバープロセスの自動化：自動化ツールを使用して、フェイルオーバープロセスを迅速かつシームレスに行い、ディザスタリカバリイベント中の人的介入を最小限に抑え、エラーの可能性を低減する。
頻繁なDR訓練の実施：定期的な災害復旧訓練を計画、実施し、計画の有効性をテストし、弱点を特定します。関係者全員が参加し、万全の態勢を整える。
データ重複排除の最適化 高度なデータ重複排除技術を使用して、バックアップに必要なストレージ量を削減し、プロセスをより効率的でコスト効果の高いものにする。
明確なRTOとRPO指標を確立する：復旧時間目標（RTO）と復旧時点目標（RPO）を明確に定義し、文書化することで、ディザスタリカバリ戦略が事業継続の目標に合致するように。

企業がMicrosoft 365のデータを保護する必要がある5つの理由

1. 誤って削除した場合

ユーザを削除すると、その意図の有無にかかわらず、その削除はビジネスアカウントとメールボックスの削除とともにネットワーク全体に複製されます。Microsoft 365 に含まれるネイティブのごみ箱とバージョン履歴では、データ損失の保護に限界があります。バックアップからの単純なリカバリは、Microsoft 365がデータを永久に削除した後、あるいは保持期間が過ぎた後に大きな問題に変わる可能性があります。

2. 保持ポリシーのギャップと混乱

保持ポリシーを含め、継続的に進化するポリシーは、管理はおろか、対応することも困難です。Microsoft 365のバックアップと保持ポリシーは限定的であり、状況に応じたデータ損失しか管理できず、包括的なバックアップソリューションとして意図されていいません。

3. 内部セキュリティの脅威

一般的にセキュリティの脅威というと、ハッカーやウイルスを思い浮かべます。しかし、企業は内部からの脅威を経験しており、それは想像以上に頻繁に起こっています。企業は、意図的であれ無意識であれ、自社の従業員による脅威の犠牲になっています。ファイルや連絡先へのアクセスはすぐに変更されるため、最も信頼してインストールしたファイルから目を離すことは困難です。マイクロソフトは、通常のユーザと、退職前に会社の重要なデータを削除しようとする解雇された従業員との違いを知る術がありません。さらに、ユーザは感染したファイルをダウンロードしたり、信頼できると思っていたサイトに誤ってユーザ名やパスワードを流出させたりすることで、知らず知らずのうちに深刻な脅威を作り出しています。

4. 外部からのセキュリティ脅威

ランサムウェアのようなマルウェアやウイルスは、世界中の企業に多大な損害を与えている。企業の評判だけでなく、社内データや顧客データのプライバシーやセキュリティも危険にさらされています。外部からの脅威は、電子メールや添付ファイルを通して忍び込む可能性があり、特に感染したメッセージが非常に説得力があるように見える場合、どのような点に注意すべきかをユーザに教育するだけでは必ずしも十分ではありません。定期的なバックアップは、感染していないデータの別コピーを確保し、データの復旧をより確実かつ簡単にするのに役立ちます。

5. 法的およびコンプライアンス要件

法的措置が取られる中で、不意に電子メールやファイル、その他の種類のデータを復元する必要が生じることがあります。マイクロソフトはいくつかのセーフティネット（訴訟ホールドとリテンション）を組み込んでいますが、これらはユーザ企業を法的トラブルから守る強固なバックアップソリューションではありません。法的要件、コンプライアンス要件、アクセス規制は業界や国によって異なり、罰金、罰則、法的紛争はどの企業も遭遇したくないものです。

株式会社クライムではMicrosoft 365ユーザのデータを保護を手助けする多くのソリューションを提供しています。

クラウドバックアップの社会的通念#10:　ほとんどバックアップとアーカイブのツールは、バックアップとアーカイブのみのツールだ

誤り：ほとんどのソリューションでできることは限られていますが、バックアップやアーカイブ以上の機能を持つツールもあります。次のような高度な機能を提供するソリューションもあります：

●eDiscoveryとジャーナリングオプション
●高速検索機能
●保存およびアーカイブされたデータからのビジネス洞察と分析

クラウドバックアップについて迷いがありましたらクライムまでお問合せください。

クラウドバックアップの社会的通念#9: バックアップとアーカイブ・ソリューションは遅い

誤り：それは非効率な場合だけです。洗練されたバックアップ・アーカイブソリューションは、最近更新または追加されたファイルを優先的にバックアップし、プロセス全体を高速化します。これにより、プロセスが迅速化され、データが完全に安全にバックアップされます。

クラウドバックアップの社会的通念#８：データを取り戻すにはお金が必要

誤り：データを人質に取らないソリューションもあります。重要なアドバイス：適切なソリューションを選択する際には、他のソリューションやサービスに移行する際にデータを取り戻すための費用が発生するかどうかをプロバイダーに確認してください。

クラウドバックアップの社会的通念#７：クラウド・バックアップとアーカイブのソリューションはすべて同だ

誤り：むしろ、下記のこれらが真実です：

市場に出回っているソリューションの多くは、UXデザインが貧弱で、使い勝手が悪い。

これらのソリューションの多くは、エージェントとしてダウンロードしなければ動作しない。

バックアップとアーカイブは別物であり、ほとんどのベンダーは一緒に提供していない。

多くのソリューションはモジュールとして販売されており、非常にコストがかかる。

バックアップとアーカイブのソリューションのうち、保存やアーカイブされたデータに基づく洞察や分析を提供するものはごく少数である。

さらに、ほとんどのソリューションは、カレンダーやタスクなど、すべてをバックアップしているわけではない。

クラウドバックアップの社会的通念#６：バックアップとアーカイブは大げさであり、不可欠ではない

誤り：データ漏洩により、企業（北米）は平均461万ドルを失っている。包括的なバックアップ・アーカイビング・ソリューションにかかる月々数ドルと比較すれば、バックアップ・アーカイビングがいかに不可欠であるかがわかるだろう。多くの企業（まだ存続している企業もあれば、廃業した企業もある）が、このことを痛感している。

クラウドバックアップの社会的通念#5: 必要なのは規制対象企業のみ

誤り:規制対象外の企業は、データのバックアップとアーカイブに価値を見出しています。以下はその使用例です：

●監査では、少なくとも 6 年前にさかのぼる完全かつ正確なデータ記録の提出が求められることが多い (IRS、SEC など)。

●訴訟や規制当局の調査により、Microsoft 365/Google Workspaceのデータを改ざんや削除できないように法的保留が必要になる場合がある。

●アーカイブシステムにある高速ユニバーサル検索ツールを使用すると、ワンクリックでソリューション全体の検索クエリを高速化できます。

クラウドバックアップの社会的通念#４：バックアップ＆アーカイブ・ソリューションは、データ・セキュリティを確保するために使用するには難しすぎる。

誤り：この考え方は、特定のバックアップシステム/ソリューションが、ソフトウェアを動作させる前提として、管理者がエージェントをダウンロードしてインストールする必要があることに起因しています。しかし、あるプロバイダーはより簡単でユーザーフレンドリーなシステムを持っています。これらのプロバイダーは、顧客が独自のバックアップ自動化システムを素早くセットアップすることを可能にし、ワンクリック復元オプションと相まって、バックアップとアーカイブを可能な限り手間のかからないものにします。

クラウドバックアップの社会的通念#2: クラウド・バックアップとアーカイブは高すぎる

誤り: 適切なソリューションであれば、1シートあたり月額数ドルで無停止のデータ保護が可能です。データ漏洩による企業の損害は平均461万ドル（前年比10％増）であり、データ・セキュリティを確保するために必要な費用を大幅に上回っています。

クラウドバックアップの社会的通念#1: Google Workspace / Microsoft 365はすでにバックアップとアーカイブを行っています。

誤り：Microsoft 365は、削除したメールとファイルをごみ箱に最大90日間保存するだけです。Google Workspaceは、エンドユーザーのDriveファイルとメールを30日後にゴミ箱とスパムフォルダに削除します。どちらのソリューション/プロバイダも、ユーザーエラー、データ破損、ランサムウェアの脅威が発生した場合のデータの完全な復元を保証するものではありません。マイクロソフトでは、サードパーティによるデータのバックアップをとっておくことを推奨しています（マイクロソフトサービス契約セクション6b）。

クラウドバックアップの社会的通念#3: クラウドバックアップは安全ではない

誤り：このような考えは、いくつかのソリューションの可視性の欠如によって助長されている。ローカルサーバーにデータを保存するのとは異なり、ローカルレベルで障害が発生しても、クラウドベースのデータで問題が発生することはありません。軍用レベルの暗号化と、大規模で安全なデータ保存のために特別に設計されたサーバーを提供するバックアップおよびアーカイブソリューションを見つけましょう。

スナップショット＆イメージレベルバックアップ

サーバ仮想化の基本要素である、1台のホスト上に存在するすべてのVMは、物理サーバのリソースを共有し、1つのハイパーバイザによって管理されていることを忘れてはいけません。もし、これら全てのVMが同時にバックアップジョブを開始したらどうなるのでしょうか？ハイパーバイザーやホストサーバのリソースに負担がかかり、遅延が発生したり、最悪の場合バックアップが失敗したりする可能性があります。

ここでスナップショットの威力が発揮されます。スナップショットはVMのある時点のコピーを取得し、フルバックアップと比較してはるかに迅速な処理が可能です。スナップショット自体はバックアップではありませんが、イメージベースバックアップの重要な構成要素です。VMスナップショットがバックアップと同等でない主な理由は、VMから独立して保存できないからです。このため、スナップショットの取得頻度によっては、VMのストレージ容量が急速に増大し、パフォーマンスに影響を与える可能性があります。このため、取得するスナップショットの数量を認識することが重要です。

AWSスナップショットの限界

単一のAWSアカウントと比較的少数のリソースを持つユーザーにとって、バックアップの自動化と一貫したポリシーの適用は簡単なプロセスです。しかし、複数の地域に多数のAWSアカウントを持つユーザーにとって、バックアップを監視しながらすべてのアカウントで一貫したデータ保護を実施することは、非常に困難でコストがかかる可能性があります。Kubernetesのようなアプリケーションでは、ITチームはより洗練されたデータ保護メカニズムを必要とし、スナップショットだけに頼っていては復旧目標を達成できないかもしれないので、問題はさらに複雑になります。

さらに、すべてのバックアップが異なる地域の異なるアカウントにコピーされることを保証する問題もあります。地域間で何千ものバックアップを移行するのは非常に高価であり、一般的なエグレス・チャージよりは低いものの、AWSは地域間のデータコピーに課金することになります。最後に、AWSのスナップショットはストレージ効率が良いが、長期間保存するとかなりコストがかかる可能性があります。

AWSスナップショットと3-2-1バックアップルール

効果的なバックアップとリカバリのシステムは、バックアップの古典的な3-2-1ルールに従っています – データのコピーを少なくとも3つ、少なくとも2つの異なるタイプのメディアに保存し、そのうち1つはオフサイトに保存します。

2つの異なるストレージシステムにデータを保存することは、プライマリシステムがダウンした場合にコピーが破損しないようにするためのリスク管理戦術です。このため、常に別のバックアップシステムを持ち、プライマリとバックアップの両方に同じストレージを使用しないようにします。スナップショットを作成した時点で、データのコピーを別のシステムに保存していることになるので、このルールの一部はAWSスナップショットを使用して簡単に遵守することができます。

少なくとも1つのバックアップコピーをオフサイトに保存することが、厄介な部分です。AWSスナップショットを別のリージョンにコピーすることは可能ですが、自動化するのは難しく、コストもかかります。あるリージョンから別のリージョンにデータをコピーすると、イグレスチャージが発生し、コストのかかる不要なコピーが作成されます。また、この概念をすべてのAWSアカウントに一貫して適用し、一元的な管理とレポーティングを維持することは困難です。

初めに：AWSスナップショットとは何ですか？

AWSスナップショットとは、EC2インスタンスやEBSボリュームなどのリソースのイメージコピーで、AWSアカウント内のオブジェクトストレージに保存される。フルまたはベースラインスナップショットは、保護されたリソースの単一時点からの同一コピーである。最初のスナップショットが作成されると、それ以降の増分スナップショットには、最後のスナップショットが取得された後に変更されたすべてのブロックが含まれるようになります。

AWSスナップショットは完全なコピーであるため、破損または削除されたリソースを復元するために使用することができ、一般的にプライマリコピーが破損した場合、ITが最初に検索するものです。例えば、EC2インスタンスやEBSボリュームが破損しても、スナップショットには影響しないので、チームは簡単に復旧することができます。

これは、AWSスナップショットがバックアップのための理想的なデータソースであることを意味します。それは、異なるシステムに格納されているデータの独立したコピーを提供します。そらは、AWSで損傷したリソースを回復するための最も簡単で迅速な方法であり、シンプルでスピーディな災害復旧のための素晴らしいリソースを示しています。

<<続き>>

https://www.climb.co.jp/faq/faq-category/aws-snapshot

クライムAWSソリューション群

初めに：Azure-backup

Azure バックアップのための実践的なヒントとチェックリスト集です。

https://www.climb.co.jp/faq/faq-category/Azure-backup

初めに: AWS-cost

AWSのコスト最適化モデルを最大限に活用するために適切な計画を立てるヒントなどを特集しています。

https://www.climb.co.jp/faq/faq-category/aws-cost

適切なEC2インスタンスタイプを選択する

EC2サービスは、おそらくAWSでのクラウドの旅で最初に選ぶものの1つだろう。60以上のインスタンスタイプがあり、最適なものを選ぶのは至難の業です。まずは、インスタンスの目的を考えてみてください。それを元に、以下のリストを見て最適なタイプを絞り込むことができます。

使用ケース |汎用機、計算、ストレージ、ネットワークでバランスが取れている必要がある
例 | Apache、NGINX、Kubernetes、Docker、VDI、開発環境など。
好ましいインスタンスタイプ｜T3

使用ケース |高性能CPUの恩恵を受けるコンピュートバインドアプリケーション
例 | 高性能ウェブサーバー、拡張性の高いマルチプレイヤーゲーム、動画エンコーディングなど
好ましいインスタンスタイプ｜C4、C5

使用ケース |大容量のデータセットをメモリ上で処理するアプリケーション
例 | 高性能データベース（SAP HANAなど）、ビッグデータ処理エンジン（Apache SparkやPrestoなど）、ハイパフォーマンス・コンピューティング（HPC）など
好ましいインスタンスタイプ｜X1およびR5

使用ケース |浮動小数点数の計算、集中的なグラフィックス処理、またはデータのパターンマッチング
例 | 機械学習/深層学習アプリケーション、計算金融、音声認識、自律走行車、または創薬
好ましいインスタンスタイプ｜G4、F1、P3

使用ケース |大量のシーケンシャルリード/ライト操作、または大規模なデータセットの処理
例 | NoSQLデータベース（例：Cassandra、MongoDB、Redis）、スケールアウト・トランザクション・データベース、データウェアハウス
好ましいインスタンスタイプ｜D2とi3

ライトサイジングとは、性能要件を満たした上で、最も安価なオプションを選択することであることを忘れないでください。経験則では、長期間にわたってインスタンスのリソース使用率が80%になるようにすることです。

サービスの利用を予測し、前もってコミットすることを目指す

パブリッククラウドの柔軟性とCAPEXからOPEXへの移行について紹介しますが、請求書を減らすAWSの機能であるリザーブドインスタンス（RI）と節約プランのいくつかは、皮肉にもCAPEXに戻るように見えます。しかし、実際に50%以上の割引が得られるのですから、誰もが「導入のベストプラクティス」リストに挙げるべきものでしょう。

RIは、EC2インスタンスの時間単位の割引料金とオプションの容量予約を提供するもので、まずRIを検討することから始めます。1年または3年のコミットメントと引き換えに、インスタンスコストの割引を受けることができます。オンデマンドインスタンスは、無制限の柔軟性でワークロードをプロビジョニングしたい人には良い選択肢です。しかし、負荷が予測可能なワークロード（Webサービスなど）を常時稼働させる場合は、RIの方がはるかに優れています。

オブジェクトストレージに感謝

AWSは、パフォーマンス、可用性、耐久性の要件を満たすように設計された複数のストレージ階層を、異なる価格で提供しています。提供されるストレージサービスは、大きく3つに分類されます。オブジェクトストレージ、ブロックストレージ、ファイルストレージです。Amazonが提供するオブジェクトストレージ、Simple Storage Service（S3）は、3つのストレージカテゴリの中で最もコスト効率が高いです。Amazon S3内では、さらに先のストレージクラス間でデータを簡単に移動させ、アクセス頻度と価格のバランスを取りながら、ストレージコストを最適化することができます。すべてのストレージタイプで利用シーンが異なり、その価格設定も様々です。

AWS S3ストレージクラス部分比較

ここでの賢い方法は、タスクの種類、オブジェクトの性質、アクセス頻度に応じて、それらを組み合わせることです。目的のS3バケットをクリックし、「管理」→「分析」を選択し、「ストレージクラス分析」を追加すると、アクセスパターンを確認するのに便利です。One Zone-IAやS3 Glacierへの移行を推奨するものではありませんが、データをより深く可視化することができます。

S3 バケット・ストレージ・クラス分析

新規者についてもしっかり検討しましょう。S3 Intelligent Tiering。少額の追加料金で、アマゾンは自動的にアクセスデータのパターンを検出し、オブジェクトの人気度に応じて、標準的なアクセスと不定期なアクセスの2つの層の間でそれらを移動させます。人気のないオブジェクト（連続30日間アクセスされていないもの）は、アクセス頻度の低い階層に移動され、要求があれば後で戻されます。この仕組みでは検索料がかからないため、オブジェクトは永遠に行き来することができます。実際のシナリオでは、20%の節約になります。このような監視のための費用を支払うことで、理論上は部分的に低くなりますが、それでも見逃すにはあまりに魅力的だからです。S3 APIまたはCLIを使用してストレージクラス “INTELLIGENT_TIERING “を指定するか、ライフサイクルルールを設定することでこの技術を有効にすることができます。

しかし、これはすべてに有効なわけではないです。128KB未満のオブジェクトは、インフリークエントアクセス層に移行されることがないため、フリークエントアクセス層の通常料金で課金されることになります。また、30日未満のオブジェクトは、最低30日間課金されるため、この方法は使えません。

ライフサイクルポリシーに慣れる

ライフサイクルポリシーといえば、AWS S3を使って運用する際には必ず必要なものです。とはいえ、ライフサイクルポリシーを実装するには、インフラ上で有効にする前に、ある程度の学習とドキュメントを読むことが必要です。

ポリシーは、使用パターンが明確に定義されたオブジェクトに対するルールの組み合わせなので、以下のことが可能です。

●ライフサイクル・ルールを使用して、オブジェクトをそのライフタイムを通じて管理する。
●階層型ストレージへの移行を自動化し、コスト削減を図る
●保管の必要性やサービスレベルアグリーメント（SLA）に基づき、オブジェクトを失効させる。

これは、適切に設定すれば非常に強力なツールです。S3ストレージクラスの違いを学び、より組織のニーズに合うようにライフサイクル・ルールに慣れることです。

ライフサイクルルールの作成

マルチパートの不完全なアップロードをクリーンアップ

S3のマルチパートアップロード機能は、デフォルトで有効になっており、大きなオブジェクトを論理的な部分に分割して並行してアップロードすることで、アップロードを高速化します。問題は、これらのアップロードが何らかの理由で終わらない場合です。アップロードが完了しないデータはバケットに表示されず、自動的に削除されることもないので、毎月の請求額が大きくなる場合を除いては、特に気にする必要はないでしょう。これを防ぐには、「バケット管理」の設定で、新しいライフサイクルルールを作成し、「不完全なマルチパートのアップロードをクリーンアップする」オプションを有効にしてください。