Amazon ElastiCache updates minimum TLS version to 1.2
Today we are updating the minimum supported TLS version to 1.2 on Amazon ElastiCache compatible with open-source Redis version 6 and above, across all regions. This update is designed to help you meet security, compliance, and regulatory requirements. Amazon ElastiCache supports the Transport Layer Security (TLS) encryption protocol, which is used to secure data in-transit over the network. TLS ve
Amazon CloudFront のアクセスログを集計して TLS バージョンの使用状況をカウントしてみる | DevelopersIO
いわさです。 TLS 1.3 について調べていると、現在では多くのブラウザやクライアントアプリケーションのデフォルト挙動として TLS 1.3 がサポートされていることがわかりました。 現在は TLS 1.2 は非推奨とはなっていませんが、ALB など一部のサービスではセキュリティポリシーとして TLS 1.3 のみを許可するポリシーが用意されています。 私には今後の動向を予想できる能力はないのですが、現在のクライアントのサポート状況からすると TLS 1.3 以上が強制される未来に備えておいたほうが良いと思っています。 前述のとおり多くのクライアントでは TLS 1.3 が自動で使用される状況ですが、一部のレガシーブラウザ、あるいはクライアントアプリケーションの実装によっては TLS 1.2 が使われている場合があります。 そこで、まずは TLS 1.2 のサポートをしない場合にどの程度
AWS Network FirewallのアウトバウンドのTLSインスペクションを試してみた | DevelopersIO
Network FirewallでTLSのトラフィックを検査したい こんにちは、のんピ(@non____97)です。 皆さんはNetwork FirewallでTLSのトラフィックを検査したいなと思ったことはありますか? 私はあります。 通常、Network FirewallではTLSのトラフィックにおいて暗号化された内容を確認することはできません。例えばHTTPSのパスをチェックすることはできません。 2023年の3月と少し前ですがNetwork FirewallでインバウンドのTLSトラフィックの検査ができるようになっています。これによりクライアントとエンドツーエンドでTLSを用いて暗号化している場合もNetwork Firewallで検査できるようになりました。 AWS Blogsでも紹介されていました。 上述のブログで紹介されているとおり、ステートフルルール評価前に復号化して評価後
Amazon ECS Service Connect で TLS 証明書を使用したトラフィック自動暗号化のサポートを開始
Amazon Elastic Container Service (Amazon ECS) の、ECS Service Connect と呼ばれるネットワーク機能向けに、Transport Layer Security (TLS) 証明書を使用したトラフィックの自動暗号化のサポートが開始されました。このサポートにより、ECS Service Connect を使用して、アプリケーションでネットワークトラフィックを暗号化して安全な接続を確立できます。ECS Service Connect を使用したトラフィックの自動暗号化は、業界最先端の暗号化機能を使用してサービス間の通信を保護し、セキュリティ要件を満たすのに役立ちます。 このリリースにより、Amazon ECS が AWS Private Certificate Authority (AWS Private CA) と統合され、証明書の発
Amazon CloudFront で RSA-4096 の証明書に対応しました | DevelopersIO
こんにちは、森田です。 以下のアップデートで Amazon CloudFront で 4096 ビットの RSA 証明書についても設定ができるようになりました。 アップデート以前までは、CloudFrontでのサポートは、RSA 証明書のパブリックキーについては、最大長は 3072 ビットまででした。 今回のアップデートで、4096 ビットの RSA 証明書を採用することで、クライアントとCloudFront間のセキュリティが強化されることが期待できます。 本記事では、実際に適用させるまでの手順と動作確認まで行ってみます。 前提条件 AWS Certificate Manager (ACM)にすでに4096 ビットの RSA 証明書についてはインポート済みとします。 また、ACM が発行する RSA 証明書のキーの最大長は 2048 ビットなので、インポートを行う必要があります。 手順をこ
AWS ELB Application Load Balancer にTLSクライアント認証(mTLS)のパススルーを構成する | DevelopersIO
ども、大瀧です。 re:Inventがまだ始まっていないのにALBがmTLSをサポートする大型のアップデートが来ました。本ブログではパススルー構成をLambdaターゲットグループで試してみた様子をご紹介します。 設定方法 設定は非常にシンプルです。ALB作成ウィザードのHTTPSリスナー選択時に表示されるセキュアリスナーの設定に「クライアント証明書の処理」という項目が増えているので、「相互認証(mTLS)」のチェックをオンにすればOKです。 ALBのmTLS対応には二つの動作モード、「パススルー」と「トラストストアで検証」があります。「パススルー」はALBでクライアント証明書の検証はせず、転送するリクエストヘッダにクライアント証明書を付与してバックエンドターゲットでの検証を期待する動作、「トラストストアで検証」は ALB自身でクライアント証明書を評価する動作です。「トラストストアで検証」を
[アップデート] Amazon S3 に二重層サーバーサイド暗号化が追加されました。 | DevelopersIO
Amazon S3 に追加された二重層サーバーサイド暗号化(DSSE-KMS)により、さらに強力なデータ保護とコンプライアンス対策を実現できます。 こんにちは、AWS事業本部の平木です！ Amazon S3 のサーバーサイド暗号化のオプションに二重層サーバーサイド暗号化 (DSSE-KMS) が追加されたため、このブログでは DSSE-KMS の概要について記載します！ DSSE-KMS とは 今回のアップデートには、以下のように説明されています。 Customers can now apply two independent layers of server-side encryption to objects in Amazon S3. Dual-layer server-side encryption with keys stored in AWS Key Management Se
![[アップデート] Amazon S3 に二重層サーバーサイド暗号化が追加されました。 | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/26ddcbeeebba3c0b350413c7b63ddf812112d927/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2022%2F08%2Famazon-s3.png)
Amazon CloudFront が、CloudFront-Viewer-TLS-header で TLS バージョンと暗号スイートの提供を開始
CloudFront が、オリジンリクエストポリシーで使用するために CloudFront-Viewer-TLS ヘッダーを提供するようになりました。CloudFront-Viewer-TLSは、ビューアのTLS接続のネゴシエーションに使用されるTLSバージョンと暗号スイートを含む HTTP ヘッダーです。従来は、TLS 情報は、以前のリクエストを分析するために CloudFront アクセスログで利用可能でした。これで、各 HTTP リクエストの TLS バージョンと暗号スイートにアクセスして、古い TLS バージョンでリクエストを制限するなどのリアルタイムの決定を行うことができるようになります。CloudFront-Viewer-TLS ヘッダー値は次の構文を使用します: <TLS version>:<Cipher Suite>例えば、TLSv1.2:ECDHE-RSA-AES128-
知られたくないドメインのSSL/TLS証明書を取得する場合は証明書の透明性(CT)を無効にしよう(AWS Certificate Manager編) | DevelopersIO
知られたくないドメインのSSL/TLS証明書を取得する場合は証明書の透明性(CT)を無効にしよう(AWS Certificate Manager編) SSL/TLS証明書(以下証明書)には証明書の監視や監査を行って証明書の信頼性を高める「Certificate Transparency(証明書の透明性;以下CT)」という仕組みがあります。 Certificate Transparency : Certificate Transparency CAが証明書を発行する際には、パブリックなCTログサーバーに発行履歴を登録し、ログサーバーから受け取った署名付きのタイムスタンプ(SCT;Signed Certificate Timestamp)を埋め込んだ証明書を発行します(埋め込まない方法も有り)。 ブラウザは証明書に埋め込まれたSCTを確認し、存在しなければ証明書を不正とみなします(ブラウザによ
AWS Certificate Managerを利用してSSL/TLS認証書をリクエストしてCloudFrontに統合してみた。 | DevelopersIO
こんにちは、イムチェジョンです。 今回のブログではACM（AWS Certificate Manager）を利用してSSL/TLS(Secure Sockets Layer/Transport Layer Security) 認証書をリクエストしてみました。 また、取得したSSL/TLS 認証書をCloudFrontに統合することまでまとめました。 アジェンダ SSL/TLS 認証書、AWS Certificate Managerとは？ ACMでSSL/TLS認証書をリクエスト まとめ 1. SSL/TLS 認証書、AWS Certificate Managerとは？ 1-1. SSL/TLS SSL（Secure Sockets Layer） インターネット接続を安全に維持し、システム間で送信されるすべての機密情報を保護 犯罪者がすべての情報(個人情報の可能性がある情報を含む)読んだり修
Amazon API Gateway がサードパーティー CA と ACM Private CA からの証明書での相互 TLS のサポートを開始
Amazon API Gateway では、セキュアな接続の確立前にデジタル証明書をクライアントと API Gateway の間で交換して、証明書ベースの相互 TLS を使用してクライアントを認証できます。以前は、API Gateway で相互 TLS を設定する場合にサーバー証明書として使用することができたのは、AWS Certificate Manager (ACM) によって発行された証明書だけでした。本日より、お客様は、サードパーティーの認証機関 (CA) または ACM Private CA によって発行されたサーバー証明書を使用できます。 この機能によって、ACM から発行されたものではない既存のサーバー証明書を使用することが可能になります。例えば、組織の情報セキュリティポリシーに準拠するためにプライベート CA によって発行されたサーバー証明書を使用する必要があるお客様の場合
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
