Security Center で警告された「CRR Configurations」への対応について紹介します。
先に結論を言うと CRR とは Alibaba Cloud の Object Storage Service の Cross-Region Replication のこととなり、今回の記事では実際に CRR を有効にする手順まで紹介します。
まず CRR Configuration と言われても何のことか想像できません。 Security Center の説明を確認します。
CRR は Cross Region disaster Recovery のことのようです。 また、この警告は OSS (Object Storage Service)に関するものなので OSS のデータ（Buckets）をリージョンをまたいで（cross-region)バックアップを構成しましょう、ということです。また、1つのリージョンの中でのバックアップとなる SRR(Same Region Replication) でもよいとのこと。
セキュリティを考える際、3つの要素があります。 「機密性」（Confidentiality）、「完全性」（Integrity）、「可用性」（Availability）の3つですが、ここでは「可用性」（Availability）について複数リージョンにデータを保持することでセキュリティリスクを軽減しようということになります。
CRR can meet your requirements for cross-region disaster recovery and data replication. Requirement: Create CRR tasks or SRR tasks.
解決策は以下。
Enter the OSS management console, select the bucket list ->select the corresponding bucket ->Data security ->Cross region replication, same region replication. Check if the data security settings meet the requirements.
実際に Alibaba Cloud Object Storage Service の設定を確認し、対応を進めます。
Security Center からの説明だと設定個所は Buckets にある ->Data security ->Cross region replication, same region replication ですが、実際の画面では異なり、以下のスクリーンショットの通り Data Management の配下に CRR と SRR がありました。
CRRの設定画面です。
説明文には、ほぼリアルタイムに同期されること、作成だけだけではなく削除などの操作も同期されるとのこと。 これはつまり人間なりプログラムが意図的にも意図せずとも削除した場合にはその削除された状態が複製されるということです。 データの削除に対処するためのバックアップというよりは Disaster Recovery の用途になるといえます。
※実際にCRRを構成する際、削除を同期するかしないか選択できることが判明
また、クロスリージョンなのでトラフィックの従量課金は発生するとのこと。
SRR の設定画面です。
こちらも CRR 同様にほぼリアルタイムな同期となる旨の説明があります。
また、CRRと異なり同じリージョンの中なのでトラフィックに関する課金は発生しないとのこと。 そして CRR の画面には全く記載がなかったリクエスト数の考え方についても記載があり、SRRではリクエストに関する課金は発生しないとのこと。
※別のマニュアルにCRRではリクエストに関する課金が発生する旨の記載を確認
今回ですが、私の OSS のバケットには重要なデータは無いため（Action Trailのログデータくらい）、CRR ではなくSRR を構成しようと思いましたが現時点で 1GB もバケットを消費しておらず大した課金も発生しないと思うのと実験的な意味で CRR 構成にチャレンジします。
まずは バックアップ先となるバケットを作成します。
- リージョンは Singapore （別にどこでもよかったのですが）
- Storage Class は Standard （バックアップ用途なので IA や Archive などより安価なものを選んでもよいかもですが現時点で1GB もないためまずは Standardで）
- Redundancy Type は既定の ZRS から LRSへ（オリジナルのバケットがLRSなのにこっちをZRSにしてもアンバランスのため）
- Block Public Access は有効に、その結果として ACL も Private へ （この設定で CRR のバックアップ先に出来るかどうかは不明。やってみて失敗したら変更する）
バックアップ元のバケットの CRR の設定画面に移動します。
- Destination Bucket で先ほど作成したバックアップ先となる別リージョンのバケットを指定
- Replicate Policyでは既定の Add/Change から Add/Delete/Changeへ（削除も含めた同期へ）
CRR の有効化の確認のダイアログ。
上記の確認のダイアログで Enable をクリック後、同期が開始されます。 Replication Status は Enabling となっていまｓ。
数分もたたないうちに Replication Status は完了しました。
この記事の最初の目的は Alibaba Cloud Security Center でリスクとして案内された CRR が未設定という状況の解消でした。 CRR を構成した状態で再度 Security Center を確認します。
しかし、Status は Not Passed のままです。
詳細を確認すると原因がわかりました。 もともと警告を受けた Bucket は Passed になっていますが、先ほど CRR のレプリケーション先として作成・設定した Bucket が Not Passed になっています。
この状況を解消するにはバックアップ先の Bucket をまた CRR なり SRR を構成することになりますが、その後にまた同じ状況が繰り返されるだけです。 ということでバックアップ先の Backet について Add to Whitelist することにしました。
Status が Whitelist となりました。 これで設定作業は終了となります。
非常に簡単かつ短時間でリージョンまたぎのバックアップを構成することができました。 ここらへんは Public Cloud のすばらしさですよね。 別の国にデータのバックアップを構成したいという目的を即座に開始でき、また、辞めることも簡単です。
以上
