Amazon Web Services ブログ

Category: Technical How-to

Okta を使用した Amazon Connect のシングルサインオン設定

IT リソースへのアクセスを保護することは非常に重要です。従業員が使用するウェブベースのアプリケーションの数が増えるにつれて、ログイン認証情報を記憶しておくことは困難になります。多くの企業では、リソースへのアクセスを合理化し、従業員のルーチンを簡素化するために、さまざまな ID プロバイダーによるシングルサインオンを採用しています。Amazon Connectは、SAML 2.0準拠のIDプロバイダーを使用したコンタクトセンターへの認証を提供可能です。このBlogでは、OktaをAmazon ConnectのIDプロバイダーとして使用するために必要な手順についてご説明します。 Oktaは、SAML 2.0認証を使用したSingle Single-Onサービスとして、最も一般的に使用されているプロバイダーの1つです。Oktaのセットアップ方法は他のSAML プロバイダーの設定とほとんど同じですが、本投稿ではOktaを使用するためのステップを具体的にご説明します。これは、一般的なガイダンスであるAmazon ConnectでのID管理用にSAMLを設定するを簡略化したものになっています。

Read More

AWS IoT Core を用いた認可ポリシーのスケーリング

はじめに IoTソリューションを構築するソリューションアーキテクト、開発者、およびシステム設計者は、ソリューション全体において、データとデータを操作する機能を適切に保護する必要があります。この投稿では、 AWS IoT Core を使用したマルチユーザーおよびマルチデバイスのユースケースに焦点を当て、認可ポリシーのスケーリングのためのいくつかの設計手法について説明します。デバイス、ユーザー間のカーディナリティやスケールのレベルに応じたパターンを紹介します。 AWS IoT サービス上にソリューションを構築する際のセキュリティ設計やアーキテクチャ検討時に活用頂ければと思います。 IoT デバイス、ネットワークパス、エンドユーザーデバイス、データベース、バックエンドシステムなど、データのやり取りが発生するあらゆるコンポーネントにおいてセキュリティ対策が必要です。IT セキュリティにおいて、セキュアなアーキテクチャを検討する際には、「AAA」と言われる3つのAを考慮する必要があります。 それぞれ、 Authentication (認証)、 Autorization (認可)、 Accounting (アカウンティング)または Auditing (監査)です。 AAA は、セキュリティ要件を整理し、それらの要件とソリューションアーキテクチャを対応付ける方法です。この方法により、ソリューションの利害関係者、エンドユーザー、およびコンプライアンスの専門家は、関連する重要な要件を満たすために、どのようにソリューションが設計されているかを把握することができます。 IoT ソリューションは、固有の設計要素をもつ分散システムアーキテクチャを意味します。分散システムアーキテクチャでは、補完的な分散セキュリティソリューションが必要になります。多くのお客様は、クラウド内の分散システムや、クラウドとオンプレミスのエンタープライズシステムを統合するハイブリッドアーキテクチャの ID (認証)機能を実現するために、 ID フェデレーション( ID 連携)を使用しています。この手法は IoT のデータと機能の保護にも利用できます。 AWS ID フェデレーションオプションの詳細については、 ID フェデレーションの記事をご覧ください。 ID の強固なソリューションを導入すれば、2番目の「A」である認可の要件への対応に集中できます。 IoT ソリューションの開発者が直面する一般的な認可のユースケースに焦点を当てます。一般的に、ユーザー、デバイス間の構成は 1:1 、もしくは 1:多となることが多いため、以降ではそれらのケースについて例をご紹介します。 単純なユースケース: 1 ユーザー 1 デバイス(1:1) 1 ユーザーが 1 つのデバイスを利用するケースは、最も理解しやすく、 IoT […]

Read More

オンラインの方法を使用して、Amazon DocumentDB に移行する

Amazon DocumentDB (MongoDB 互換) は、MongoDB のワークロードをサポートする高速でスケーラブル、かつ可用性に優れた完全マネージドのドキュメントデータベースサービスです。お客様は、基盤となるインフラストラクチャの管理を気にすることなく、現在ご使用のものと同じ MongoDB 3.6 向けのアプリケーションコード、ドライバー、ツールを、そのまま Amazon DocumentDB 上でワークロードを実行、管理、そしてスケールするのに使えます。ドキュメントデータベースである Amazon DocumentDB は、JSON データの保存、クエリ、およびインデックスを容易にします。 MongoDB から Amazon DocumentDB に移行するには、オフライン、オンライン、ハイブリッドの 3 つの主なアプローチがあります。詳細については、Amazon DocumentDB への移行を参照してください。 この投稿では、オンラインアプローチを使用して、オンプレミス、あるいは EC2 にホストされた自己管理型の MongoDB クラスターを Amazon DocumentDB に移行する方法について説明します。オンラインのアプローチがダウンタイムを最小限に抑えます。これは、DMS が移行元の MongoDB の oplog から継続的に読み込み、ソース の Amazon DocumentDB クラスターにほぼリアルタイムでそれらの変更を適用するからです。オンラインの方法のデモについては、Video: Live migration to Amazon DocumentDBをご覧ください。 ダウンタイムを最小限に抑え、ソースデータセットが小さい (1 TB 未満) 場合は、オンライン方法が最適です。データセットが 1 TB より大きい場合は、ハイブリッドまたはオフラインのアプローチを使用して、mongorestore […]

Read More

Amazon EKS ワーカーノードの謎を解くクラスターネットワーク

AWS で Kubernetes を実行するには、AWS のネットワーク設定と Kubernetes のネットワーク要件の両方を理解する必要があります。デフォルトの Amazon Elastic Kubernetes Service (Amazon EKS) の AWS CloudFormation テンプレートを使用して、Amazon Virtual Private Cloud (Amazon VPC) と Amazon EC2 ワーカーノードをデプロイすると、通常の場合、すべて機能します。しかし、設定に小さな問題があると、エラーが発生してイライラさせられることがあります。 このブログでは、Amazon VPC を設定するさまざまな方法を見ながら、Amazon EKS が管理する Kubernetes クラスターの EC2 ワーカーノードを実行します。ノードがクラスターコントロールプレーンに接続できるようにサブネットが適切に設定されていることを確認する方法について、特に注目します。 このブログでは、VPC CNI、サブネットのサイズ設定、ポッドの IP アドレス割り当てなどのポッドネットワーキングの概念については取り上げません。これらのトピックの詳細については、EKS ドキュメントをご覧ください。 注 – VPC とノードの Cloudformation テンプレート、および EK が管理するノードグループがパブリック IP アドレスをノードに割り当てる方法を変更しています。詳しくは ブログをご覧ください。 EKS クラスターのアーキテクチャ EKS クラスターは […]

Read More