AWS Verified Access が GA となったので IAM Identity Center を信頼プロバイダーとしてグループポリシーを設定して使ってみた いわさです。 re:Invent 2022 で AWS Verified Access がパブリックプレビューで登場していました。 VPC 内のプライベートなアプリケーションに信頼された IdP を使って、構成されたポリシーをクリアしている場合など一定条件を満たしているとパブリックなエンドポイントを経由したプライベートネットワーク上の Web アプリケーションへ接続させることが出来るサービスです。 そんな AWS Verified Access が本日 GA となりました。 プレビュー時点からいくつか機能が追加されているのですが、そもそも DevelopersIO に実際に使った記事がないことに気が付きました。 そこで、本日は
Today, AWS announces the general availability of AWS Verified Access, a service that helps you provide secure access to your corporate applications without using a VPN. Built based on AWS Zero Trust principles, you can use Verified Access to implement a work-from-anywhere model with added security and scalability. Verified Access evaluates each access request in real time based on the user’s ident
2017年10月末のアップデートにより、Amazon ElastiCache for Redis が通信の暗号化とクライアント認証に対応しました。 通信の暗号化(encryption in-transit)を使うと アプリとRedis間の通信(encrypted connections) プライマリ↔レプリカなどのRedis間の通信(encrypted replication) が暗号化されます。 また、Redis の AUTH コマンドによるクライアント認証にも対応したため、認証レベルを強化できます。 これらの機能追加により、個人を特定できる情報(PII)など機密度の高い情報を扱うシステムでAmazon ElastiCache for Redisを導入しやすくなりました。 それでは、実際に使ってみましょう。 なお、同時に機能追加された、保管時の暗号化は次のブログをご確認下さい。 Amaz
セキュリティグループのルール棚卸しを行う機会は多いです。 例えば以下のようなケースです。 AWS Security Hub 『基礎セキュリティのベストプラクティス』の EC2.2: VPC のデフォルトのセキュリティグループでは、インバウンドトラフィックとアウトバウンドトラフィックが禁止されます コントロールに失敗したセキュリティグループ AWS Config の restricted-ssh で非準拠になったセキュリティグループ それらセキュリティグループは是正する必要があります。 しかし是正前に使用状況を確認して、影響範囲を把握しておきたいです。 今回はセキュリティグループ使用状況の把握を AWS CloudShell を使って行います。 特定のセキュリティグループが関連付けられている ENI/EC2インスタンス情報を取得します。 0. 前提条件 対象のリージョンで AWS Confi
こんにちは。 ご機嫌いかがでしょうか。 "No human labor is no human error" が大好きなネクストモード株式会社の吉井 亮です。 日本国内においても多くのシステムがクラウド上で稼働していることと思います。 俊敏性、拡張性、従量課金、IaS、セキュリティなどクラウドのメリットを享受しやすい所謂 SoE で多くの実績があるように感じます。 ここ1~2年は、社内基幹システム・情報システム、SoR 系のシステムのクラウド移行が本格化してきたというのが肌感覚であります。 クラウドでのシステムインフラ構築は従来のようにゼロから非機能要件定義を行っていくものではなく、ベストプラクティスをまず実装して少しずつ微調整を行っていくものと考えています。とはいえ、システムごとの要件は予め明らかにしておくことがインフラ構築においても重要になります。 クラウド上では出来ること出来ないこと
いつも忘れないように、コンセプトから。 コンセプト ・お金かけてまでやりたくないのでほぼ無料でAWSを勉強する →ちょっとしたサービスを起動すると結構高額になりやすい。 ・高いレベルのセキュリティ確保を目指す →アカウントを不正に使われるととんでもない額を請求されるので防ぐ いろいろ忙しかったので久しぶりにお勉強をはじめました。コロナでリモートワークなので通勤時間分は空いているはずなんですが、その分勉強するかというとやってないですね。。。朝起きてちょっとして仕事をはじめ、終えて寝る。時間はちょっとずつありますが、ダラダラ過ごしてしまい、良くないなと思う今日この頃です。 AWSブログ(セキュリティ) さて、先週末にちょっと興味深いAWSブログが公開されてました。DoDというのはアメリカ国防総省ですが、そこでセキュリティのレベル認定を行っていて、そのレベル4をパスしたサービスが追加されたという
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 と統合されたサービス ACM AWS Certificate Manager では、 の数が増えています。 AWS サービス。ACM 証明書またはプライベートをインストールできない AWS Private CA 証明書を で直接 AWS ベースのウェブサイトまたはアプリケーション。 パブリックACM証明書は、Nitro Enclave に接続されている Amazon EC2インスタンスにインストールできますが、他の Amazon EC2インスタンスにはインストールできません。 AWS Nitro EnclavesNitro Enclave に接続されていない Amazon EC2インスタンスでスタンドアロンウェブサーバーを設定する方法については、「チュートリアル:
{ "Statement":[ // S3ホームディレクトリでバケット一覧を表示するために必要 { "Effect":"Allow", "Action":[ "s3:ListAllMyBuckets" ], "Resource":"arn:aws:s3:::*" }, // バケットに対する操作を許可 { "Effect":"Allow", "Action":[ "s3:ListBucket", "s3:GetBucketLocation" ], "Resource":"arn:aws:s3:::bucket" }, // オブジェクトに対する操作を許可 { "Effect":"Allow", "Action":[ "s3:PutObject", "s3:GetObject", "s3:DeleteObject" ], "Resource":"arn:aws:s3:::bucket/*"
EC2にHTTPSでアクセスするための設定をご紹介します. また, ドメイン名をすでに持っているという前提で話を進めます. 自分のサーバーのappache環境を載せておきます. $ httpd -v Server version: Apache/2.2.34 (Unix) 安全な通信とはHTTPSとHTTPの違いは, 通信の安全性が保証されているかにあります. HTTP通信では, AさんがBさんへ送信した通信内容が, 第三者Cさんに盗聴, 改ざんされるおそれがあります. 一方でHTTPS通信では, 通信内容が暗号化されているため, HTTPと比較すると安全に通信を行うことができます. しかし, 通信内容が暗号化されているだけでは十分に安全とは言えません. Aさんがデータを送信している相手がBさんであれば安全ですが, 送信先が実はBさんではなく第三者Cさんであった場合, Aさんは気づかずに重
Amazon Web Services ブログ AWS Microsoft ADとオンプレミスの資格情報を使用してAWS管理コンソールにアクセスする方法 これは、AWS Security blogに投稿された「How to Access the AWS Management Console Using AWS Microsoft AD and Your On-Premises Credentials」の翻訳記事です。 AWS Microsoft ADと略される、AWS Directory Service for Microsoft Active Directory は、AWSクラウドにホストされた管理されたMicrosoft Active Directory(AD)です。オンプレミスのAD管理ツールを使用して、AWSリソースを管理する権限をユーザに簡単に付与できます。AWS Micro
人間のユーザーが AWS にアクセスする際は、一時的な認証情報の使用を必須とすることをお勧めします。AWS IAM Identity Center の使用を検討したことのある場合 IAM Identity Center を使用すると、複数の AWS アカウント へのアクセスを一元的に管理できます。ユーザーには、割り当てられたすべてのアカウントに対する MFA で保護された Single Sign-On によるアクセスを、1 つの場所から提供することができます。IAM Identity Center では、 その内部でユーザー ID の作成および管理を行います。あるいは、既存の SAML 2.0 互換 ID プロバイダーにも簡単に接続することができます。詳細については、「AWS IAM Identity Center ユーザーガイド」の「What is IAM Identity Center
NATインスタンスとNATゲートウェイの違いで混乱したのでまとめます。 まずそれぞれについてとても軽く説明 #NATインスタンス NATインスタンス プライベートサブネットはインターネットからのアクセスを受け付けないため パッチのダウンロードやS3やDynamoDBのようなリージョンサービスへのアクセスができません。 それを可能にするのがNATインスタンスで、実体はそのEC2インスタンス。 AWSからNATインスタンス用のAMIも提供されています。 プライベートサブネット内からのトラフィックを受け付け、 プライベートIPをNATインスタンスのグローバルIPに変換して外との通信を可能にします。 ポイントとして、 ・NATインスタンスの送信元/送信先チェック(Change Source/Dest.Check)を無効化する必要がある ・NATインスタンスにグローバルIPの割り当てが必要(EIPで
AWSでのNAT接続を実現する方法を備忘を兼ねて記載。 NATインスタンス編はこちら NAT構成の必要性 簡単にいうと、 インターネットから接続される必要のないインスタンスについて、 インターネットからの接続を遮断しつつ、 自身はインターネットに接続を出来るようにするため。 外部から接続される危険性を減らすことと、 ライブラリの取得などで必要になる外部への接続の両立が可能となる。 参考 シナリオ 2: パブリックサブネットとプライベートサブネットを持つ VPC(NAT) http://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/UserGuide/VPC_Scenario2.html NATゲートウェイ http://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/UserGuide/vpc-nat-gatew
はじめに AWSにはEC2やRDS、RedshiftなどVPCに対応したサービスが数多くあります。 これらのサービスを利用する場合、まずはVPCやサブネットを作成します。 VPCの作成ではIPアドレス(=CIDR)に何を指定するか迷う方が多いのではないでしょうか。 私がVPCとサブネットのCIDRを決める際に考慮しているポイントは、ざっと以下の通りです。 プライベートIPアドレス範囲から指定する VPNやDirect Connect利用時はオンプレミスとの重複に注意する VPCピア利用時はVPC間で重複できない 将来の拡張に対応可能なCIDRを選択する 最低でも/28以上が必要 CIDRブロックのうち、5IPは利用できない ELBを配置するサブネットは/27以上のCIDRかつ、少なくとも8個の空きIPを用意する それぞれの詳細をご紹介し、最後に優先順位をまとめます。 プライベートIPアドレ
Amazon Virtual Private Cloud (Amazon VPC) を使用すると、論理的に隔離されている定義済みの仮想ネットワーク内で AWS リソースを起動できます。仮想ネットワークは、お客様自身のデータセンターで運用されていた従来のネットワークによく似ていますが、AWS のスケーラブルなインフラストラクチャを使用できるというメリットがあります。 以下は、AWS Management Console を使用した VPC の作成時に表示される [プレビュー] ペインの VPC とそのリソースを視覚的に表現したものです。既存の VPC の場合、この図には [リソースマップ] タブからアクセスできます。この例では、VPC と他のネットワークリソースの作成を選択した際に [VPC を作成] ページで最初に選択されるリソースを示しています。この VPC は、1 つの IPv4 CI
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く