Amazon Web Services ブログ

Azure MFAサーバーを使用したAmazon WorkSpacesの多要素認証(Multi-Factor Authentication)

EUC Specialized SAの渡邉(@gentaw0)です。Amazon WorkSpaces は、AWS で稼働するマネージド型でセキュアな DaaS (Desktop-as-a-Service) ソリューションです。Amazon WorkSpaces を使用すると、仮想的な、クラウドベースの Microsoft Windows デスクトップを簡単にプロビジョニングし、ユーザーは必要なドキュメント、アプリケーション、リソースにサポートされている任意のデバイスから、いつでもどこでもアクセスできるようになります。Amazon WorkSpacesでは多要素認証(Multi-Factor Authentication)をサポートしており、オンプレミスまたはクラウド上のRADIUSサーバーと連携することにより認証のセキュリティを強化することが可能です。 多要素認証(MFA)とは、本人確認(認証)する方法として複数の手段を使う事です。認証にパスワードを使用する事が多いかと思いますが、これは本人だけが知っているはずの情報を確認して、認証を行います。MFA を使用する場合は、このパスワードに加えてトークン等が生成するワンタイムパスワード(OTP)も確認する事で、本人しか持っていないはずのトークン(物)も持っている事を確認して認証できます。 Amazon WorkSpaces での認証は、フルマネージド型のディレクトリサービスであるMicrosoft AD、または既存の Active Directory で認証するための AD Connector を選択することができます。お客様は MFA で使用するワンタイムパスワードを認証できる RADIUS サーバーを別途用意する必要があります。RADIUS サーバーはオンプレミスにあっても、AWS 上にあっても構いません。RADIUSに対応しているものであればさまざまな製品を利用することが可能ですが、このブログ記事ではそのなかでもAzure Multi-Factor Authenticationサーバーを使用してAmazon WorkSpacesのMFAを構成する方法について解説します。 ディレクトリの構成 まず、MFAを有効にするためのディレクトリを作成します。現在のところ、以下のタイプのディレクトリでMFAを構成することが可能です。Simple ADはMFAに対応していないため、このシナリオでは利用することはできません。 AD Connector Microsoft AD オンプレミスまたはVPC上にすでにActive Directoryドメインを展開する場合は、AD Connectorを使用します。VPC上に独立したActive Directoryドメインを作成する、またはオンプレミスのActive Directoryドメインと信頼関係を結ぶ場合はMicrosoft ADを使用します。AD Connectorの作成方法については、こちら(https://docs.aws.amazon.com/ja_jp/directoryservice/latest/admin-guide/create_ad_connector.html)、Microsoft ADの作成方法についてはこちら(https://docs.aws.amazon.com/ja_jp/directoryservice/latest/admin-guide/create_managed_ad.html)のドキュメントを参照してください。ディレクトリの作成が完了したら、AWSマネージメントコンソールからAD ConnectorもしくはMicrosoft ADのIPアドレスを確認しておきます。  Azure […]

Read More

AWS Database Migration Service を使用した Amazon RDS for SQL Server の継続的なレプリケーションの紹介

AWS Database Migration Service (AWS DMS) とAmazon RDS for SQL Server が新たに Amazon RDS for SQL Server からの継続的なレプリケーションをサポートするという新機能を発表できることを嬉しく思います。AWS DMSは、データベースをAWSに迅速かつより安全に移行できるサービスです。また、AWS内のデータ移行にも使用できます。Oracle、Microsoft SQL Server、PostgreSQLなど、広く普及している商用およびオープンソースデータベース間でデータを移行できます。このサービスはSQL ServerからSQL Serverのような同エンジン間の移行と、SQL ServerからAmazon Aurora MySQLまたはSQL ServerからAmazon RDS for MySQLなどの異なるデータベースプラットフォーム間の移行の両方が可能です。 この記事では、Microsoft SQL Server からの継続的なレプリケーションプロセスの概要を簡単に説明します。また、MS-CDC(SQL Serverでの変更データキャプチャ)とAWS DMSを使用して、Amazon RDS for SQL Serverからの継続的な変更をストリーミングするための新機能も紹介します。   背景 AWS DMSは異なるエンジン間の移行(SQL ServerからMySQLへの移行など)用に設計されています。ただし、同エンジン間(SQL ServerからSQL Serverなど)の移行もサポートしています。これまではソースインスタンスで実際に行われていた変更にアクセスする必要がありました。 主キーを持つテーブルの場合、AWS DMSはデフォルトで以下のように使用されるように設計されています。 1.SQL Serverから進行中の変更を移行するタスクを設定すると、AWS DMSは最初に次のコマンドを使用してトランザクションレプリケーション用のデータベースを有効にします。 use master exec sp_replicationdboption […]

Read More

AWS SCT と AWS DMS を使ってMySQLから Amazon Aurora に移行する方法

MySQLは素晴らしいオープンソースデータベースエンジンで、そのコスト効率から多くの企業で使われています。しかし、その他のオープンソースデータベースと同様に、ビジネスで使えるレベルの性能を出すには多くの労力が必要です。 データベースサイズが増えるとMySQLのスケーラビリティとクラッシュリカバリの複雑さも増します。レプリケーションスレーブを追加することでMySQLデータベースをスケールさせると、特にMySQLマスターで多くの書き込みが発生した場合に、レプリケーションラグを非常にに小さな値で維持することは困難を伴います。ほとんどの場合、安定したパフォーマンスを維持することは難しいです。 一方、Amazon Aurora では最大15個のリードレプリカを追加できます。また、書き込みノードで発生した変更を再実行するために必要な従来のバイナリログ (binlog) レプリケーションのパフォーマンスをAuroraでは気にする必要がなくなります。これはAuroraクラスターボリューム内のデータは、クラスター内のライターとリーダーに対して単一の論理ボリュームとして見えるためです。 多数のテーブルを含む大規模なデータベースでの高速リカバリも Amazon Aurora の重要な利点の一つです。従来のMySQLの実装では、データベースが大きくなるにつれてリカバリ時間が長くなります。MySQLはREDOログファイルを使用するため、クラッシュするとMySQLはテーブルの検出や検証オペレーションを大量に実行します。データベースの表領域が大きいほど、リカバリに必要な時間は長くなります。この影響は MySQL 5.7 でも当てはまります。 このような要因から、MySQLから Amazon Aurora への移行に関心が集まっています。この移行を実行するにはいくつかの方法がありますが、今回は Amazon RDS for MySQL またはオンプレミスや Amazon EC2 上のMySQLから Amazon Aurora with MySQL compatibility への同種間移行について考えます。 同種間移行の方法 AWSホワイトペーパーのサイトにある Amazon Aurora Migration Handbook で同種間移行のための推奨方法がリストされています。Amazon RDS for MySQL から移行するのであれば、RDSスナップショットでの移行方法を使用できます。この方法では、RDS MySQL のDBインスタンスのスナップショットから Aurora MySQL DB クラスターを作成します。これは非常に簡単です。Amazon Aurora へニアゼロダウンタイムで移行した場合は、ソースとなる RDS MySQL DBインスタンスからAuroraリードレプリカを作ることができます。RDSが Amazon Aurora […]

Read More

MongoDB クラスターから Amazon DynamoDB へのライブマイグレーションの実行

あるデータベースから別のデータベースへのデータ移行は、データの整合性、アプリケーションのダウンタイム、ターゲットとソースデータベース間の重要な設計の違いに関して、相当難易度が高くなる場合があります。AWS Data Migration Service (AWS DMS) は、MongoDB、Oracle、MySQL、Microsoft SQL Server などのデータベースの素早く、安全で、シームレスな AWS への移行を支援します。ソースデータベースは移行中もほとんど動作し続けるため、データベースに依存するアプリケーションのダウンタイムを最小限に抑えることができます。 この記事では、シャーディングされた MongoDB クラスターのライブデータを Amazon DynamoDB のテーブルにシームレスに移行するためのアプローチを説明します。Amazon DynamoDB は、あらゆる規模で一貫性のある 1 桁ミリ秒台のレイテンシーが必要なアプリケーション向けの、完全マネージド型、高速、スケーラブル、柔軟なクラウドデータベースサービスです。この記事で説明されているアプローチは、ほぼダウンタイム無しで移行を実施し、AWS DMS を使用してソースデータを変換し、少数のアクセスパターンを提供します。 DynamoDB と MongoDB のコンポーネント間のマッピング 移行を実施する前に、Amazon DynamoDB と MongoDB のコンポーネントを簡単に比較してみましょう。DynamoDB と MongoDB の多くのコンセプトは類似しており、どちらも JSON のようなデータを柔軟でダイナミックなスキーマでアプリケーションに保存することができますが、いくつかの点で大きく異なります。 このセクションでは、DynamoDB のコアコンセプトをいくつか説明し、DynamoDB と MongoDB のコンポーネントを比較します。MongoDB のコンセプトの詳細については、MongoDB のマニュアルを参照してください。 主要なコンポーネント Amazon DynamoDB で用いる主要なコンポーネントは、テーブル、項目、および属性です。テーブルは項目の集合であり、各項目は属性の集合です。DynamoDB では、テーブルのアイテムを一意に識別するためプライマリキーを使用し、クエリの柔軟性を高めるためにセカンダリインデックスを使用しています。各テーブルはそれぞれに対応するインデックス、キャパシティー、スケーラビリティの設定がある分離されたユニットです。DynamoDB と MongoDB は、どちらもデータセットを項目の集合に分割することが可能です。 以下の表は DynamoDB […]

Read More

Amazon EC2 テストポリシー

ネットワークストレステスト 【日本語訳】日本時間 2018年02月08日09:00 このポリシーは、お客様の Amazon EC2 インスタンスから、他の Amazon EC2 インスタンス、AWS プロパティ/サービス、外部エンドポイントのような他の場所へ、大規模なネットワークテストを直接実施することを計画しているお客様に関係するものです。 これらのテストは、ストレステストや負荷テスト、ゲームデーテストと呼ばれることがあります。このポリシーでは、テストにおいて正当な大規模トラフィックあるいはテストトラフィックを特定の対象アプリケーションに対し送信する行為を「ネットワークストレステスト」とします。エンドポイントとインフラストラクチャは、このトラフィックを処理できる必要があります。 このポリシーは、通常のプロダクションのトラフィックとは関係ありません。ネットワークストレステストは、多くの場合、特定のエンドポイントを対象とし、送信元や対象が集中することを含め、通常とは異なるトラフィックパターンを持ち、持続的に大規模なトラフィックが発生し、予期している上限値を超える可能性があるため、通常のプロダクションとは異なります。ネットワークストレステストにおけるこれらの違いは、外部エンドポイント、他のお客様、AWS サービスに対し意図しない影響を与えうる潜在的なリスクとなります。 パケットや接続のフラッディング、それ以外の大規模なトラフィックで、ターゲットやインフラストラクチャへ意図的に過大な負荷をかけるテストは、ネットワークストレステストではなく、分散型 DoS (DDoS) テストとして扱われます。ボリュームのあるネットワークベースの DDoS シミュレーションは、Amazon EC2 プラットフォームでは明示的に禁止されています。このポリシーは、https://aws.amazon.com/security/penetration-testing の範囲のセキュリティやペネトレーションテストは対象としません。 ほとんどのお客様はこのポリシーには該当しません。通常、ユニットテストのように大規模なワークロードをシミュレートするストレステストでは、ネットワークストレステストに該当するだけのトラフィックは生成されません。このポリシーは、お客様のネットワークストレステストによって、Amazon EC2 インスタンスで以下の基準を満たすトラフィックが生成されたときに適用されます。”持続的に 1分以上の間 1 Gbps(秒間 1億ビット)あるいは 1Gpps(秒間 1億パケット)を超えるトラフィック、悪用目的や悪意があるように見えるトラフィック、テスト対象以外(ルーティングや共有サービスのインフラストラクチャなど)へ潜在的に影響を及ぼしうるトラフィック” などが該当します。 お客様は、対象のエンドポイントへのテストが承認され、その起こりうる規模について理解している必要があります。いくつかの外部エンドポイントや AWS サービスは、ある種のテストシナリオに対して期待する閾値よりも低い性能しか発揮できない可能性があります。 AWS を利用する多くのお客様は通常のプロダクションモードで定期的に 1Gbps もしくは 1Gpps 以上のトラフィックを生成していることを確認しております。これは完全に正常であり、特にネットワークストレステストの目的のために実施されたものではない限り、このポリシーの範囲下ではありません。 このポリシーの基準を満たすネットワークストレステストにはリスクがあります。お客様が悪質であると検知され報告されるリスク、お客様が意図せず悪質となり他の対象に影響を及ぼすリスク、お客様が所有するインスタンスで機能制限を受ける可能性などがあり、この際にはテストだけではなく、プロダクションのワークロードへ影響する可能性があります。 実施するテストがこれらの基準を満たすか、お客様で不明な場合は、このポリシーに従い、AWS 側にテストの評価を依頼する必要があります。お客様の体験や、その他の影響を受ける可能性があるサービスを改善していくため、これらのストレステストを実行する前には、Amazon EC2 ネットワークストレステストを申し込みフォームから申請してください。このフォームは aws-security-simulated-event@amazon.com へメールを送ることで入手できます。 お客様のネットワークストレステストが 外部や他の AWS サービスのような EC2 インスタンス以外から直接実行される場合、フォームからの申請が必要かどうかメールでお問い合わせください。 […]

Read More

AWS Cloudtrail Logs を AWS Glue と Amazon Quicksight 使って可視化する

AWS CloudTrail ログを簡単に視覚化できることは、AWS インフラストラクチャがどのように使用されているかについてより良い理解を提供してくれます。また、AWS API コールの監査とレビューを行って、AWS アカウント内のセキュリティ異常を検知するためにも役立ちます。これを行うには、CloudTrail ログに基づいた分析を実行できる必要があります。 この記事では、Amazon S3 内の AWS CloudTrail ログを JSON 形式からクエリ用に最適化された形式のデータセットに変換するための AWS Glue と AWS Lambda の使用について詳しく説明します。その後、Amazon Athena と Amazon QuickSight を使用してデータをクエリし、視覚化します。 ソリューションの概要 CloudTrail ログを処理するには、以下のアーキテクチャを実装する必要があります。 CloudTrail は Amazon S3 バケットフォルダにログファイルを配信します。これらのログを正しくクロールするには、S3 バケットの単一フォルダ内に変換済みファイルを格納する Amazon S3 によってトリガーされる Lambda 関数を使ってファイルコンテンツとフォルダ構造を変更します。ファイルが単一のフォルダ内にある場合、AWS Glue はデータをスキャンし、それを Apache Parquet フォーマットに変換して、Amazon Athena と Amazon QuickSight を使用したクエリと視覚化を可能にするためにカタログ登録します。   チュートリアル ソリューションを構築するために必要なステップを見て行きましょう。 CloudTrail ログのセットアップ 最初に、S3 バケットにログファイルを配信する証跡をセットアップする必要があります。CloudTrail […]

Read More

AWS Glue : ネストされた JSON を Relationalizeトランスフォーム

AWS Glue には、ネストされた JSON をリレーショナルデータベースに簡単にインポートできるカラムに変換することによって抽出、変換、ロード (ETL) プロセスをシンプル化する、Relationalize と呼ばれるトランスフォームがあります。Relationalize は、ネストされた JSON を JSON ドキュメントの最外部レベルでキーと値のペアに変換します。変換されたデータでは、ネストされた JSON からの元のキーのリストが、ピリオドで区切られた形で維持されます。 サンプルユースケースを使って Relationalize がどのように役立つかを見てみましょう。 Relationalize の実行例 ビデオゲームの開発者が、JSON 形式で保存されたデータに基づいてプレイヤーの行動についてのレポートを実行するために Amazon Redshift などのデータウェアハウスを使用したいとしましょう。サンプル 1 は、ゲームからのユーザーデータ例を示しています。「User1」という名前のプレイヤーには、ネストされた JSON データ内に種族、クラス、ロケーションなどの特徴があります。さらに下に行くと、プレイヤーの武器情報に追加のネストされた JSON データが含まれています。開発者がデータウェアハウスに対してこのデータの ETL を行いたい場合、コードではネストされたループや再帰的関数を用いなければならないかもしれません。 サンプル 1: ネストされた JSON { “player”: { “username”: “user1”, “characteristics”: { “race”: “Human”, “class”: “Warlock”, “subclass”: “Dawnblade”, “power”: 300, “playercountry”: “USA” }, […]

Read More

AWS Glue and SneaQLを使ったAmazon Redshift へのUpsert

この記事は、Full 360 のソリューションアーキテクトである Jeremy Winters と Ritu Mishra によるゲスト投稿です。2 人によると、「Full 360 はクラウドファースト、クラウドネイティブのインテグレーターで、2007 年の創立以来の忠実なクラウド信者です。私たちの焦点は、クラウドへの旅におけるお客様の援助であり続けています。ビッグデータとウェアハウジング、アプリケーション近代化、そして Cloud Ops/戦略といった私たちの業務分野は、深いだけではなく、明確な専門知識を表しています。」 AWS Glue は、簡単でコスト効果の高い方法でデータの分類、消去、強化、およびさまざまなデータストア間を確実に移動することができる、完全マネージド型 ETL (抽出、変換、ロード) サービスです。 10年もの間クラウド内にデータウェアハウスソリューションを構築してきた企業として、Full 360 はカスタマーソリューションで AWS Glue をどのように活用できるかについて興味を持っていました。この記事では、当社が Amazon Redshift データ統合ユースケースのための AWS Glue の使用からの得た経験と教訓について詳しく説明していきます。 UI ベースの ETL ツール 当社では、re:Invent 2016 で AWS Glue が発表された当時からそのリリースを心待ちにしていました。私たちの顧客の多くは、データ変換パイプラインを管理するための使いやすい UI ベースのツールを探しています。しかし当社の経験では、どの生産パイプラインの複雑性も、それらを作成するために使われたテクノロジーに関わらず、解消しづらい傾向にあります。Full 360 では, データ統合を処理するためにコンテナにデプロイされたクラウドネイティブなスクリプトベースのアプリケーションを構築しており、スクリプトベースの変換は、発生するデータ問題に対応するために必要なロバスト性と柔軟性のバランスを提供すると考えています。 AWS Glue は、スクリプトを記述することを好む開発者と、UI ベースのインタラクションを望むユーザー両方の要望に応えます。データのソースとターゲットを選択することにより、UI を使ってジョブを初期に作成することが可能です。AWS Glue は内部で Python […]

Read More

Amazon Relational Database Service – 2017 年を振り返って

2017 年には Amazon RDS チームによって、およそ 80 個もの機能がリリースされました。一部はこのブログでもご紹介しましたが、AWS データベースブログや AWS の最新情報またはフォーラムの投稿でもご紹介しています。今週のしめくくりに、これらの情報を振り返って整理したいと思います。ではご紹介します! 認証とセキュリティ 1 月 – FedRAMP Certification for Amazon RDS for MySQL, Oracle, and PostgreSQL 2 月 – Forced SSL Support for SQL Server 4 月 – AWS IAM で RDS for MySQL と Amazon Aurora データベースへのアクセスを管理 6 月 – TDE Encrypted Cross-Region Snapshots for RDS […]

Read More

AWS Schema Conversion Tool によるTrimble社のデータベース移行を成功させた秘訣とは’s データベース移行の成功

Trimble 社の フィールドサービス管理部門 (FSM) でインフラストラクチャ運用部のディレクターである Todd Hofert 氏による寄稿。 状況 最近、 Trimble 社のフィールドサービス管理部門のインフラストラクチャ運用グループは、非公開でホストされている SaaS サービスをアマゾン ウェブ サービス (AWS) に移行する積極的な取り組みに着手しました。同部門は、ハードウェアのリフレッシュ、継続的なコスト削減の必要性、 AWS 上の同社の次世代プラットフォームと従来の商品を調和させたいという必要性に直面しました。これに対応して、 Trimble 社のインフラストラクチャチームは、データウェアハウスソリューションから始まる包括的な移行計画を策定しました。 コスト削減、可用性、スケーラビリティは、 AWS イニシアチブへの主な推進力でした。Trimble 社は、Oracle からオープンソースデータベースプラットフォームに移行することで、現在のライセンスコストを最適化することに決めました。また Trimble 社は、 Amazon RDS を使用してデータベースを動作させることで、信頼性を保証し、運用サポートの間接費を削減することにも力を入れました。 データベースの選択 Trimble 社の運用とデータベース開発チームは、 AWS チームを招き入れて、 Oracle から離れたデータベースプラットフォームへの移行に関する難易度を調べました。この評価の中心となったのは、 AWS Schema Conversion Tool (AWS SCT) 評価レポートでした。 Trimble 社のチームは AWS SCT を使用して、ソースである Oracle データベースと Amazon Relational […]

Read More