Amazon s3 にIPアドレス制限をかけるときの注意点

##目的

災害対策として、オンプレサーバのバックアップを、クラウドにも保存する。いわゆるディザスタリカバリ。

###クラウドサービスの選定

Amazon s3を選定。理由は、オンプレサーバのバックアップ先(NAS)にs3と連携できる機能が標準で付いていたため。

###ざっくりな流れ
AWS側でs3バケット作成
↓
オンプレ側でs3への接続設定

##s3バケット作成

妙な言い回しでひっかかる設定項目があったが、既に先人の知恵がございましたので、ここでの説明は割愛。

そして先人に盛大なる感謝。

S3のブロックパブリックアクセスが怖くなくなった

セキュリティを確保するため、オンプレサーバのグローバルIPからs3へのアクセスのみ許可するようなポリシーを設定します。(JSON形式で)

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Principal": "*",
            "Action": "s3:*",
            "Resource": "arn:aws:s3:::bucket-name",
            "Condition": {
                "NotIpAddress": {
                    "aws:SourceIp": [
                        "xxx.xxx.xxx.xxx/32"
                    ]
                }
            }
        }
    ]
}

注意すべきはこのときです！

グローバルIPを間違えて入力してしまったもんなら、もうそのバケットに対して何も操作出来なくなります。
もしバケット操作不可になった場合は、ルートユーザでAWSマネジメントコンソールにログインすれば、ポリシー変更なり削除なりの操作が可能です。

なんらかの代行サービスを経由してAWSアカウントを取得している場合は、ルートユーザでの操作ができない場合がありますので、ご注意ください。

私の場合はまさにルートユーザでの操作ができないタイプのサービスでしたので、バケットがずーっと残ったままになっていますorz

##オンプレ(NAS)からS3への接続設定
NASの機種によると思いますが、必要なのはたいてい
　1.アクセスキーID
　2.シークレットアクセスキー
　3.バケット名
くらいかと思われます。
1と2は、IAMユーザのキーになります。間違ってもルートユーザのキーは作成しないように！

##おわりに
VPCやらサブネットやらセキュリティグループやらの設定に比べたら、S3の設定は全然難しくありませんでした。
でも、一歩間違えるとバケット操作できなくなる可能性がありますので、ご注意ください。