AWS勉強メモ

0x00 背景

0x01 サービス毎のメモ

  1. STS
    https://aws.amazon.com/premiumsupport/knowledge-center/iam-restrict-calls-ip-addresses/
    APIコールをIPで制限したい場合、公式にはこのようなやり方が推奨されている。自分は疑問に思うのは、ここの Sample IAM User Policy の所に aws:SourceIp の制限をつけるのと Sample IAM Role Trust Policy に aws:SourceIp の制限をつけるのは違うのか？

    実際に試してみよう。
    例えば test-user-nevermoe という user にこのようなポリシーをアタッチする：

        {
        "Version": "2012-10-17",
        "Statement": {
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": "arn:aws:iam::123456789012:role/test-role-nevermoe",
            "Condition": {
                "IpAddress": {
                    "aws:SourceIp": "1.2.3.4/32"
                }
            }
        }
    }

    この場合は test-user-nevermoe という user は 1.2.3.4 からログインする時に限って、test-role-nevermoe に aAssumeRole できることが確認した。

    次に、このような Trust Policy を test-role-nevermoe にアタッチしてみよう：

        {
        "Version": "2012-10-17",
        "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::0123456789012:user/test-user-wan"
            },
            "Action": "sts:AssumeRole",
            "Condition": {
                "IpAddress": {
                "aws:SourceIp": "1.2.3.4/32"
                }
            }
        }]
    }

    この場合も同じく、test-user-wan のログイン IP が 1.2.3.4 の時にのみ、test-role-nevermoe に AssumeRole できる。

    この二つのやり方は違いがないが、role のほうに Policy で制限した方が管理しやすいかもしれない。ただし、個人的には、user を棚卸しするときの利便性を考えると、やはり user 側で IP 制限を書いた方が楽では？

  1. KMS
    KMS には Master Key が保存されており、Master Key は AWS から離れることはない。要するにユーザーである我々でも自分自身の Master Key を見ることはできない。データを暗号化する時に Data Key が発行され、データを Data Key で暗号化し (AWSがやってくれるか(Server-Side-Encryption)、ユーザー自身がやる(Client-Side-Encryption) )、平文の Data Key が破棄される (ユーザー自身で暗号化する時にユーザー自身で破棄する)。ただし Master Key で暗号化された Data Key は暗号化されたデータと一緒に保存される。復号したい時に暗号化された Data Key を KMS に復号を依頼して、平文の Data Key を手に入れる。平文の Data Key を使ってさらにデータを復号する。
    Symmetric keyは最大4096 byteの平文しか暗号化できない。Asymmetric keyはアルゴリズムによって数百byteの平文しか暗号化できない。
    CMK自動ローテーションでも、手動ローテーションでも、古いkeyで暗号化されたデータは自動的にre-encryptされない。自動ローテーションの場合はAWSが古いCMKと新しいCMKを両方内部で持ち、古いkeyで暗号化されたデータを復号する時に自動的に古いCMKを使う。手動ローテーションする場合はアプリケーション自身で古いkeyを保持して、あるいはre-encryptをしないといけない。
    Key Material を 一旦導入したら、該当CMKに他のKey Materialを導入することができない。ただし、Key Materialが削除されたら、同じKey MaterialであればCMKに導入し直すことが可能。なので、Key Material 自体をrotateすることでCMKをrotateする手段は存在しない。

  2. S3
    S3は三つの権限制御方法がある。

    1. Resource-based Policy
    2. Bucket ACL
      Bucket ACLはほとんど使わない。server access loggingをEnableした時に、TargetバケットのBucket ACLのS3 Log Delivery Groupの項目にObject:Write, Bucket ACL:Read の権限をつけないといけない。
    3. Object ACL
      これもあんまり使わないが、他のアカウントからObjectにアクセス可能かを制御している。ちなみに、Object owner (your AWS account)の権限を全部奪うと、自分のアカウントのroot userからObjectにアクセスできなくなる。

    S3のバケット、オブジェクトにリクエストする時に通常AWS CLI / SDKはリクエストを署名してくれている。この署名付きのリクエストは五分間有効だそうだ。この性質を使えば、Appを作る時にS3を活用できる：認証を通ったユーザーに署名付きのリクエストをフロントエンドに渡し、そのリクエストでS3のObjectをアクセスさせる。
    S3のServer Side Encryption方法比較：

    注意：SSE-KMSはCustomer managed keyとAWS managed key両方使える。SSE-KMSはSymmetric keyしか使えない。Server Side Encryption以外に、Client Side Encryptionも使える、これはClient Sideでdata keyを使ってオブジェクトを暗号化しておいて、S3にアップロードする方法だ。Client Side EncryptionでKMSを使う時に、data keyの生成、使用はsdkがやってくれる。ここにサンプルコードがあるけど、s3ObjectKey はObjectファイルの名前で、暗号化キーなどと一切関係ないので勘違いしないで：https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingClientSideEncryption.html

    S3のPublic Accessをブロックしても、Signed URLを使えばインタネットからアクセス可能になる。

  3. Cognito
    Cognitoには二つのPoolがある。

    1. User Pool
      User PoolはFacebook、Google、Appleみたいにユーザーを作れる。作られたUser Poolの中のUserでSign-inできる。要するにUser PoolはOAuthのIDPのような存在。
    2. Identity Pool
      Identity Poolはfederation loginする時に権限をawsにmappingする時に使う。例えばfacebookでawsにログインしたユーザーにこのaws accountのs3へのアクセス権限を付与するようなシナリオで使える。さらに、Identity Pool の Authentication providers -> Choose role with rules で facebook account 別に違うroleを付与するruleが作れる。

  4. CloudWatch
    CloudWatchには二つの機能がある。

    1. Metrics
      マシンのCPU Usage などの情報を監視。
    2. Log
      各種Logを収集し、可視化するもの。

    metricsに注目してもらいたいのは二つ：

    1. system status:
      Loss of network connectivity
      Loss of system power
      Software issues on the physical host
      Hardware issues on the physical host that impact network reachability
      system status checkが失敗した時にrecoverができる。
    2. instance status:
      Failed system status checks
      Incorrect networking or startup configuration
      Exhausted memory
      Corrupted file system
      Incompatible kernel
      instance status checkが失敗した時にrecoverできない。rebootならできる。

  5. VPC
    Internet GWがアタッチされたsubnetはpublic subnetといい、逆にprivate subnetという。Internet GWがアタッチされても、InstanceにPublic IPがついてなければInternetからInstanceにInbound通信できない。Private subnetにあるマシンはInternetとのInbound通信も、Outbound通信もできない。Private subnetにあるマシンをOutbound通信できるようにするには、NAT GWをアタッチする必要がある。
    VPC Endpointを使えば、Internet越しじゃ無くても、VPCから他のAWSサービスにアクセスできる。
    PrivateLinkというサービスは VPC の Endpoint Serviceである。VPCにあるカスタムサービスを他のVPCに共有するためのサービス。

  6. Storage Gateway
    Storage Gatewayを使うにはオンプレマシンにAWSのVMイメージをインストールする必要がある。

  7. Config

  8. Trusted Advisor
    Trusted AdvisorはSecurityだけでなく、Performance、CostなどのAWSのベストプラクティスにフィットしてないかをチェックしてくれる。Trusted AdvisorのSecurityはConfigと重複する部分もあるが、Configと違って、Trusted Advisorはルールのカスタマイズできない。

  9. その他
    kmsのkey policyは必須で、明示的に書かれたprincipalしかアクセス権限がない。一方でs3のbucket policyは必須ではないし、principalを明示的に書かなくても、role/userにs3へのアクセス権限があればアクセスできる。そしてkey policyでprincipalを"arn:aws:iam::012345678901:root" に指定すると、AdministratorAccess/KAWSKeyManagementServicePowerUserを所有しているuser/roleが自然にアクセスできるという隠れ仕様がある。推測ですが、S3にデフォルトの隠れPolicyがあって、"arn:aws:iam::012345678901:root" が必ず最初からついている状態になっている。