Category: Security, Identity, & Compliance

先日 (2018/12/19) 開催しました AWS Black Belt Online Seminar「AWS Certificate Manager」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 AWS Black Belt Online Seminar 2018 AWS Certificate Manager from Amazon Web Services Japan AWS クラウドサービス活用資料集（すべての過去資料が閲覧できます） Q. DNS検証に成功した後、Route53の該当するレコードを削除した場合、証明証の自動更新がされないなどの影響がありますか？ A. 影響がございます。こちらをご確認ください。 Q. RDSにSSL証明書があると思いますが、ACMで管理できるものですか？妄想的な質問で恐縮ですが、自動で更新されると良いかと思いまして A. ACMの管理対象ではありませんが、RDSの機能でメンテナンスウィンドウで自動更新されますが、RDSに接続するクライアント側で対応が必要な場合があります。 https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html Q. ACMで使えるドメインを教えてください A. 下記よくある質問の内容をご確認ください。 よくある質問では、複数ドメイン対応、ワイルドカードドメイン、ドメインに利用できる文字形式についての質問を掲載しております。 今後の AWS Webinar スケジュール 直近で以下のオンラインセミナーを予定しています。各オンラインセミナーの詳細およびお申し込み先は下記URLからご確認いただけます。皆様のご参加をお待ちしております！ AWS Black Belt Online Seminar 1月分申込先 ≫ Redshift […]

2018年12月20日、AWS Loft Tokyoにて、AWS re:Invent 2018で発表されたセキュリティ新サービスなど最新情報を振り返るイベントが開催されました。 AWS re:Invent 2018とは、2018年11月25日から11月30日まで米国ラスベガスで開催されたAWS最大のカンファレンスです。エンドユーザー様、パートナー様を中心に、世界中から50,000人以上の来場者、100,000以上のライブ参加者を集めました。re:Inventは、基調講演や2100を超えるブレイクアウトセッション、パートナー様ソリューション紹介、参加者同士のネットワーキングイベントなどからなります。期間中に発表された新サービスや機能アップデートは100を超えました。 そこで本イベントは、セキュリティ分野に絞り、企業のセキュリティ意思決定者・担当者に向けて効率的に情報収集いただく目的で開催されました。AWSソリューションアーキテクトによる新サービスアップデートに加えて、AWSに関わりの深いエンドユーザー様、パートナー様からAWSへの期待やAWSサービス使用時のGood Practiceを伝えていただきました！   第一部 AWS Threat Detection and Remediation Workshop 本イベントは二部構成で実施されました。第一部は新サービスAWS Security Hubを用いた実践的参加型ワークショップです。参加者は企業のセキュリティ管理者となり、AWS環境で構築しているWebサーバーを、外部脅威から保護します。複数のAWSサービスを駆使し、一早く脅威を検知し、詳細調査しながら、企業として適切なインシデント対応フローを構築します。 AWS Security Hub, Amazon GuardDuty, Amazon Macie, Amazon Inspector, Amazon CloudWatch, AWS Lambda, AWS Systems Manager, AWS Config, AWS Cloud Trail などのセキュリティサービスを講義で紹介しつつ、ハンズオンで実際触ってみて、最後に参加者自身がセキュリティ管理者だったらどのような脅威検知と対応の仕組を構築するかをディスカッションしました。 約40名の参加者からは、「実践的な内容のワークショップだったので、参考になりました。 会社でも実践してみたいと思います。」「ハンズオンで体験が出来良かったです。」「具体的に脅威へ対応する体験ができたのがよかったです」「セキュリティの設定や実際の攻撃を体験することが出来、大変参考になりました。」「実践的な流れで体験したことでそれぞれの機能の概要が、短時間で理解できた気がします。」「実際にサービスを触りながら学ぶことができたので良かったです。」「AWSセキュリティ体系の重要性と勉強の必要性を多分に感じました。」などの声をいただきました。 今後もAWS Loft Tokyoなどで同ワークショップを開催していきますので、是非ご参加ください！   第二部 AWS re:Invent 2018 Security re:Cap […]

このブログ記事では、データを保護する一般的なデータセキュリティパターンとそれに対応する AWS セキュリティコントロールに焦点を当てます。クラウド内の機密データを保護するための効果的な戦略を立てるには、一般的なデータセキュリティパターンをよく理解し、これらのパターンを明確にマッピングしてクラウドセキュリティコントロールに活かすことが必要です。

先日 (2018/11/21) 開催しました AWS Black Belt Online Seminar「AWS Key Management Service (KMS)」の資料を公開しました。 AWS Black Belt Online Seminar AWS Key Management Service (KMS) from Amazon Web Services Japan 過去資料はこちらをご覧ください。 今後の AWS Black Belt Online Seminar のスケジュール 直近で以下のオンラインセミナーを予定しています。各オンラインセミナーの詳細およびお申し込み先は下記URLからご確認いただけます。皆様のご参加をお待ちしております！ 11月分申込先 ≫  12月分申込先 ≫ AWS CloudFormation アップデート 2018 年 11 月 28 日 | 18:00 – 19:00 | IT 知識レベル:★★☆☆☆ | AWS 知識レベル:★★☆☆☆ […]

以前に説明したように、顧客はさまざまな理由で複数の AWS アカウントを使用しています。一部の顧客は、複数のアカウントを使用して管理および課金を切り分けています。爆発半径を設定して、間違いの影響をコントロールしている顧客もいます。 こうした分離はすべての顧客にとって実際にポジティブなものですが、特定のタイプの共有が有用で有益であることも判明しています。たとえば、多くの顧客は、管理のオーバーヘッドや運用コストを削減するために、リソースを一元的に作成してアカウント間で共有したいと考えています。 AWS Resource Access Manager 新しいAWS Resource Access Manager (RAM) は、AWS アカウント間でのリソース共有を容易にします。AWS 組織内でリソースを簡単に共有でき、コンソール、CLI、一連の API から使用できます。Route 53 Resolver ルールのサポートを開始 (昨日、Shaunの素晴らしい記事で発表) し、近いうちにさらに多くの種類のリソースを追加します。 リソースを共有するには、単にリソース共有を作成し、名前を付け、リソースを 1 つ以上追加し、他の AWS アカウントへのアクセス権を付与するだけです。それぞれのリソース共有はショッピングカートに似ており、異なる種類のリソースを保持できます。自分が所有しているリソースはすべて共有できますが、共有されているリソースを再共有することはできません。リソースは、組織、組織単位 (OU)、AWS アカウントで共有することができます。また、組織外のアカウントを特定のリソース共有に追加できるかどうかをコントロールすることもできます。 組織のマスターアカウントの共有を、RAM コンソールの [Settings] ページで有効にする必要があります。 その後、組織内の別のアカウントとリソースを共有すると、リソースはどちらの側でもさらなるアクションなしで利用可能になります (RAM は、アカウントが組織に追加されたときに行われたハンドシェイクを利用します)。組織外のアカウントでリソースを共有すると、そのアカウントでリソースを利用できるようにするために承認する必要がある招待が送信されます。 リソースがアカウント (消費アカウントと呼ぶ) と共有されると、共有リソースは消費アカウントが所有するリソースと共に適切なコンソールページに表示されます。同様に、Describe/List をコールすると、共有リソースと消費アカウントが所有するリソースの両方を返します。 リソース共有にタグを付け、IAM ポリシーでタグを参照してタグベースの権限システムを作成することができます。リソース共有から、いつでもアカウントやリソースを追加したり削除したりすることができます。 AWS Resource Access Manager の使用 RAM コンソールを開き、[Create a resource share] をクリックして開始します。 共有の名前 […]

  皆様、こんにちは。セキュリティソリューションアーキテクトの桐山です。 2018/10/29(月)から11/2(金)にかけて開催されたAWS Dev Day Tokyo 2018で実施された、セキュリティ関連のセッションとワークショップをおさらいしてみます。 開発者向けカンファレンスということで、この度はセキュリティに興味のある多くの開発者にご参加いただきました。これから企業がデジタルトランスフォーメーション(DX)時代に向かっていく中、開発者の役割も更に高度化・専門化しています。 事業部門で、いわゆるSysmem of Engagement(SoE)領域に携わる開発者は、下記のような今までにない新しいワークロードをセキュアに開発することに挑戦しているでしょう。 IoTサービスにより、様々なデバイスから大量の信頼性の高い実データを収集する 企業内データを一元的に集約・保存する場所(データレイク)をセキュアに管理・運用する 迅速にビジネスインサイトを活用するために、データ分析・可視化・利用をサーバーレスコンピューティング環境で実現する 上のそれぞれに相当するIoTセキュリティ、データレイクセキュリティ、サーバーレスセキュリティは新しいセキュリティ技術領域と言えます。 一方で、IT部門にて、いわゆるSystems of Record(SoR)領域に携わる開発者は、事業成長を支えるセキュリティ基盤を実現しなければなりません。ITインフラ自体を変革させると同時に、事業活動の変化やスピードに対応するためにSecurity as a ServiceやSecurity Automationに取り組むことになるでしょう。 このようなDX時代のセキュリティをAWSで実現するとしたら・・・以下のワークショップとセッションが役に立つはずです。

Amazon GuardDuty を使用して AWS アカウントとワークロードを保護すると、大量のデータをすばやく検索して可視化できるようになります。企業によっては、何千ものアカウントからアクティビティを分析しているところもあるでしょう。分析後、是正措置がとれるようにセキュリティチームに警告する必要があります。重要なのは、タイミングです。 GuardDuty に、Amazon Elasticsearch Service とデータの可視化を組み合わせることで、データを実用的な洞察に変換することができます。この記事では、Amazon ES を使用して GuardDuty の調査結果を分析する方法を示します。また、Amazon ES のオープンソースのデータ可視化プラグインである Kibana を使用して、データを検索、探索、可視化する方法を紹介します。 このようなリソースの作成を開始するための概要と手順は、次のとおりです。 ソリューションの概要と前提条件 設定方法の高水準フローは、以下に示すように次のステップから構成されています。 Amazon Cloudwatch Events と AWS Lambda を使用して GuardDuty の調査結果を収集します。それを Amazon S3 に送信します。 S3 バケットに配信されたログを Amazon ES に送信します。 Amazon ES で調査結果を分析、検索、集約します。 Kibana ダッシュボードを使用して結果を可視化します。 ここで手順を開始する前に、このAWS ブログ記事で概説しているように、マスターアカウントで GuardDuty を有効にします。マスターアカウントには、GuardDuty のすべての調査結果が集計されます。マスターアカウントは通常、セキュリティチームによって管理され、すべてのメンバーアカウントの結果が表示されます。 ステップ 1: AWS Lambda を使用して GuardDuty ログを収集し、Amazon […]

データレイクはあらゆる規模で構造化および非構造化データを格納するために使用できる集中リポジトリを提供します。データレイクには、未加工のデータセットと整理され、クエリ用に最適化されたデータセットの両方を格納できます。未加工のデータセットは本来の形式で、素早く取り込むことが可能で、事前定義されたスキーマに無理矢理押し込める必要がありません。データレイクを使用すると、未加工と整理されたデータセットの両方に異なるタイプの分析を実行できます。データレイクのストレージレイヤーに Amazon S3 を使用することで、バケットとオブジェクトレベルの両方を細かくコントロールできるようになります。レイクのデータセットのアクセスコントロールポリシーを定義するためにこれらを使用できます。 AWS Glue データカタログは、永続型のフルマネージドメタデータストアで、AWS のデータレイクに使用できます。Glue データカタログを使用することで、Apache Hive Metastore で実行するのと同じ方法で AWS クラウドでもメタデータの保存、注釈の付与、共有を実行できます。Glue データカタログはまた、Amazon Athena、Amazon EMR、Amazon Redshift Spectrum などと、シームレスで、細かな設定の不要な統合を実現できます。 AWS Glue を使用することで、ユーザー、ロールをベースにした、または、リソースレベルに適用した、カタログの異なる部分へのアクセスを制限するポリシーの作成も可能です。これらのポリシーを使って、どのユーザーがデータレイク内で種々のメタデータ定義にアクセスできるかを詳細にコントロールできます。 重要: S3 および AWS Glue データカタログのポリシーは、それぞれ、データとメタデータ定義のアクセス許可を定義します。言い換えれば、AWS Glue データカタログのポリシーは、メタデータへのアクセスを定義し、S3 ポリシーはコンテンツそのものへのアクセスを定義します。 GetDatabases、GetTables、CreateTable、およびその他の個人識別ベースのポリシー (IAM) を使用して、どのメタデータを操作できるようにするか制限できます。また、その操作で実行するデータカタログオブジェクトも制限できます。さらに、結果の呼び出しで戻されるカタログオブジェクトを制限できます。ここで言う Glue データカタログの「オブジェクト」とは、データベース、テーブル、ユーザー定義の関数、または Glue データカタログに格納された接続を指します。 データレイクの本番環境のデータベースとテーブルに読み取りアクセスが必要で、他にはリソースを開発するための追加的なアクセス権限があるユーザーがいるとします。また、未加工データのフィードとビジネスインテリジェンス、分析、機械学習などのアプリケーションで使用された整理済みのデータセットの両方を格納するデータレイクがあるとします。これらの構成を簡単に設定でき、AWS Glue データカタログのアクセスコントロールメカニズムを使用して、他のものも多数簡単に設定できるようになります。 注意: 以下の例では、AWS Glue データカタログでポリシーをセットアップする方法について解説します。関連付けられた S3 バケットやオブジェクトレベルのポリシーは設定しません。これは、Athena、EMR、AWS Glue データカタログと統合されるツールの使用時、メタデータが検出できないことを意味します。誰かが S3 オブジェクトに直接アクセスしようとしたときに、S3 ポリシーが強制されることが重要です。データカタログと S3 バケットまたはオブジェクトレベルのポリシーを一緒に使用する必要があります。 […]

多くの組織では、集中化されたユーザー管理、特に Microsoft Active Directory または LDAP が標準となっています。  AWS リソースへのアクセスも例外ではありません。  Amazon Athena は、データレイク内のデータの迅速で費用効果の高いクエリで一般的である、Amazon S3 のデータ用のサーバーレスクエリエンジンです。  ユーザーまたはアプリケーションが Athena にアクセスできるようにするために、組織は AWS アクセスキーと適切なポリシーが適用されているアクセス秘密鍵を使用する必要があります。一貫性のある認証モデルを維持するために、組織はフェデレーテッドユーザーを使用して Athena の認証と承認を有効にする必要があります。 このブログ記事では、AWS Security Token Service (AWS STS) を使用してフェデレーテッドユーザーによるアクセスを有効にするプロセスを示します。このアプローチを使用すると、一時的セキュリティ認証情報を作成して、Athena でクエリを実行する信頼できるユーザーに提供することができます。

医療情報システム向け「Amazon Web Services」（以下「AWS」）利用リファレンスが AWS パートナーネットワーク のパートナー(以下、APN パートナー)各社のサイトを通じて公開されましたので、お知らせさせていただきます。医療情報を取り扱うお客様がこの文書を活用することにより、医療情報システムの安全で効率的な構築が AWS 環境で可能となることを目指し、AWS は APN パートナー各社の皆様を継続して支援させていただいています。   -医療情報システム向け「AWS」利用リファレンスとは 日本において医療情報システムの構築・運用を行う上で遵守すべき厚生労働省、総務省、経済産業省の 3 省が定めた各ガイドラインに AWS 環境上で対応するための考え方や関連する情報を APN パートナー各社で整理検討したリファレンス文書となります。   -医療情報に関連したガイドラインおよび背景 日本では全ての医療行為は医療法等で医療機関等の管理者の責任で行うことが求められており、クラウドサービスを利用する場合も、医療情報システムの構築や運用に関連して、安全かつ適切な技術的及び運用管理方法を確立し、安全管理や e-文書法の要件等への対応を行う必要があります。こうした医療情報システムのデータは、個人情報保護法における「要配慮個人情報」に該当し、医療情報の取扱いにおいても、「収集」「保管」「破棄」を通じて、諸法令をはじめ、通知や指針等に定められている要件を満たす適切な取扱いができる仕組み作りが必要です。     医療情報システムでは、2018 年の現在において、厚生労働省、総務省、経済産業省の 3 省が定めた医療情報システムに関する各ガイドラインの要求事項に対して、医療情報に係る関連事業者や責任者が必要に応じて各種対策を施す必要があります。クラウド環境の導入を検討する場合には、これらのガイドラインの要求事項を整理検討し、必要となる対策項目の洗い出しや対応する情報、実施策の検討等を行う必要があります。     -AWS と APN パートナー様の取り組み Amazon Web Services（以下「AWS」）は、AWS の環境において、医療情報を取り扱うシステムを構築する際に参照される各種ガイドラインに対応するための「医療情報システム向け AWS 利用リファレンス」の文書の作成にあたり、AWS パートナー各社様をHIPAA等実績に基づき支援してきました。AWS は米国における HIPAA に対応した医療情報システムのクラウド基盤として多くの事業者に利用された実績を有し、セキュアで柔軟かつ低コストのクラウドサービスを実現可能なAWS環境において、医療情報システムの様々な要件に対応するため各種サービスや関連情報を提供しています。AWS はお客様の医療情報システムにおける AWS 環境の活用を今後も支援していく予定です。     -「医療情報システム向け AWS 利用リファレンス」のダウンロード先 […]