AWS 認証コネクタで安全に接続する

ジョー・ロバートソン
2023 年 1 月 26 日
分読み

Mendix AWS 認証コネクタがリリースされ、開発者が AWS に対して簡単に認証し、さまざまなサービスを使い始めることができるようになりました。

セキュリティは、もちろん不可欠です。特にAWSのような従量課金制のサービスを使用する場合は、AWSサービスとの統合時にベストプラクティスに従うことが重要です。このため、AWS認証コネクタにはさまざまな認証方法があり、その中で最も安全なのはセッション認証情報の使用です。これにより、アプリは一定期間（通常は約1時間）IAMユーザーロールを採用できます。最近リリースされたIAM Roles Anywhere機能.

コンテンツを示す画像: AWS サービスと安全に統合するためのベストプラクティス。セッションベースの認証情報。Amazon DynamoDB コネクタは、GetSessionCredentials アクションを使用して、AWS 認証コネクタから Credentials オブジェクトを要求します。AWS 認証コネクタは、Roles Anywhere を介して AWS STS を使用して一時的なセッショントークンを要求します。返された一時的なトークンは、DynamoDB コネクタを使用して DynamoDB へのリクエストに署名するために使用されます。セッションに適切なロールと設定がある場合は操作が許可され、そうでない場合は AccessDenied 例外がスローされます。

認証

この認証方法では、証明書を使用して AWS でアプリケーションを認証します。これを使用するには、クライアント証明書を取得する必要があります。独自の認証局 (CA) にアクセスできない場合、これは簡単なことではありません。

自己署名証明書を作成するには、暗号化を目的としたオープンソースのコマンドラインツールであるopenSSLを使用します。ここからopensslをインストールします、またはすることができます Gitインストールに付属するopensslを利用する.

証明書を生成する方法は他にもあります。 AWS プライベート認証局サービスまたはパブリック証明書サービス。openssl を使用する理由は 2 つあります。

コスト - これはコストがかからない無料のコマンドラインツールであり、開発とテストに最適です。
セキュリティ – パブリックCAをトラストアンカーとして使用すると、そのCAによって生成されたすべての証明書が信頼されることになりますが、ポリシー制約で制限することもできます。これはお勧めできません。

トレンチコートを着た男性が「ああ、あと一つ」と言っているミーム

これらのコマンドはWindowsとLinuxでテストされています（Macユーザーには申し訳ありませんが、同じだと思います）。Windowsを使用していて、 Mendix クラウドの場合は、openSSL バージョン 3.X がインストールされていることを確認してください。

免責事項: 独自の自己署名証明書を作成するには細部に注意を払う必要があり、使用事例に適さない可能性があります。関連するリスクを理解してください CA とキーは常に安全かつ秘密に保たれます。

自己署名証明書

ルートを作成する

最初に行うべきことは、CA および信頼アンカーとして機能するルート証明書を作成することです。これは、すべての追加証明書に署名するために使用され、次の要件があります。

PEM形式である必要があります
バージョン3である必要があります
基本制約にはCA: TRUEを含める必要があります

これを行うには、openssl.cnf ファイルを更新する必要があります。これは openssl の構成ファイルで、openssl をインストールした bin フォルダーにあります。v3_ca セクションを見つけて、以下のように更新します。

[ v3_ca ]
    basicConstraints        =critical, CA:TRUE
    subjectKeyIdentifier    =hash
    authorityKeyIdentifier  =keyid:always, issuer:always
    keyUsage                =critical, cRLSign, digitalSignature, keyCertSign

その後、秘密鍵を生成し、CA PEMファイルを作成する必要があります。キーを生成するためのRSAまたはECアルゴリズム.

openssl genrsa -out PrivateCA.key 4096
    openssl req -new -x509 -days 3650 -key PrivateCA.key -out PrivateCA.pem -extensions v3_ca

ここで、証明書の識別情報をいくつか提供できます。

openssl x509 -in PrivateCA.pem -text -noout

実際に v3 証明書を作成したことを確認することもお勧めします。

V3 証明書検証の c-path を示す画像

クライアント証明書

CA ができたので、AWS で認証情報を取得するために使用するクライアント証明書を生成できます。AWS では、使用するクライアント証明書に対して次の要件があります。

バージョン 3 (X.509v3) である必要があります
基本制約にはCA: FALSEを含める必要があります
キーの使用にはデジタル署名を含める必要があります
署名アルゴリズムには SHA256 以上が含まれている必要があります。

これらの要件を満たすには、まず、証明書を生成するときに呼び出す拡張ファイルを作成する必要があります。次の内容を含む v3.ext という名前のファイルをルート証明書と同じディレクトリに配置します。

authorityKeyIdentifier=keyid,issuer
    basicConstraints=CA:FALSE
    keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment

さて、証明書の場合は、まずキーを作成します。

openssl genrsa -out client.key 4096

次に、新しい証明書を作成します。

openssl req -new -key client.key -out client.csr

最後にルート CA で署名します。

openssl x509 -req -in client.csr -CA PrivateCA.pem -CAkey PrivateCA.key -set_serial 01 -out client.pem -days 3650 -sha256 -extfile v3.ext

これが完了すると、証明書フォルダに次のファイルが作成されます。

証明書フォルダ内の v3.ext を示す画像

証明書を弊社で使用できるようにするには、もう1つの手順が必要です。 Mendix アプリケーション: クライアント証明書をエクスポートする必要がありますアプリにアップロードできるpfx形式.

openssl pkcs12 -export -in client.pem -inkey client.key -certpbe PBE-SHA1-3DES -keypbe PBE-SHA1-3DES -macalg sha1 -out client.pfx

後で使用するパスワードを指定する必要があります。

これらの証明書を使用して、 Mendix AWS サービスへのアプリケーション。

次のステップは、ルート証明書を IAM Roles Anywhere に渡し、使用する IAM ロールに接続することです。

AWS コンソールを開き、IAM Roles Anywhere を検索します。

IAM Roles Anywhere を備えた AWS コンソールの画像

まず、ルート CA に接続された信頼アンカーを作成します。信頼アンカーに名前を付け、外部証明書バンドルで外部証明書バンドルを選択してから、PrivateCA.pem の内容を貼り付けます。

トラストアンカー編集ウィンドウを示す画像

信頼アンカーが、使用するサービスと同じリージョンにあることを確認します。

トラストアンカーを取得したら、引き受ける IAM ロールが必要になります。新しい IAM ロールを作成し、カスタム信頼ポリシーを追加します。

  {
      "Version":"2012-10-17",
      "Statement":[
        {
          "Effect":"Allow",
          "Principal":{
          "Service":"rolesanywhere.amazonaws.com"
        },
        "Action":[
            "sts:AssumeRole",
            "sts:SetSourceIdentity",
            "sts:TagSession"
          ]
        }
      ]
    }

次に、IAM ポリシーを追加する必要があります。ロールに必要な最小限の権限を付与することをお勧めします。ここでは、mendixdemo.com S3 バケットを操作する権限を付与しています。


     {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Action": [
                    "s3:PutObject"
                ],
                "Resource": "arn:aws:s3:::mendixdemo.com/*"
            }
        ]
    }

次に、このロールを引き受けるためのプロファイルが必要になります。IAM Roles Anywhereを再度検索してプロファイルを作成し、作成したロールを割り当てます。

Mendix コミュニティ

この時点で、証明書とAWSロールを使用して、 Mendix アプリ。まずはローカル開発から始めます。デモ用に、簡単なデモプロジェクトをセットアップし、マーケットプレイスから AWS 認証コネクタと S3 コネクタをダウンロードしました。

まず、AWS コネクタの設定から始めましょう。必要なのは、作成したアイテムの ARN だけです。

AWS コネクタの設定を示す画像

次に、ポリシーで定義した S3 バケットにアップロードできるように S3 コネクタを追加します。

S3コネクタの追加を示す画像

ちょっと待ってください…何か忘れていませんか？証明書を使わないのであれば、証明書生成の目的は何だったのでしょうか？証明書がどこにあるかをアプリに伝える必要があります！クライアント証明書IDを「1」に設定することから始めました。次に、ランタイム設定を更新する必要があります。アプリ->設定->構成で、 2つのカスタムランタイム構成:

ClientCertificatePasswords – pfx を生成するときに追加したパスワード。
ClientCertificates – ローカルマシン上の証明書の場所です。

顧客のランタイム構成の追加を示す画像

今これをテストすると、S3 バケットにアップロードできることがわかります。

Mendix クラウド

これをローカルで実行できるのは素晴らしいことですが、今度はクラウドにデプロイできるようにする必要があります。これにはライセンス環境が必要です。これらの手順では、「Mendix クラウド」ですが、原則は「Mendix 「プライベートクラウド向け」

最初の変更は、アプリケーション定数 AWSAuthentication.ClientCertificateID を証明書IDの値に設定する設定の更新です。証明書IDは環境で設定できます。証明書が複数ある場合は一意の値を使用する必要があるため、意味のある値を検討してください。例えば「AWS_Auth」のように。