Amazon Web Services ブログ 寄稿：株式会社ドワンゴによる「AWS で実現するニコニコの大規模セキュリティ改革の概観」 本稿は、株式会社ドワンゴ（以下、ドワンゴ）におけるクラウド環境のセキュリティ改革をリードされた青木 良樹様/結城 清太郎様/坂井 薫平様に寄稿いただきました。 はじめに 株式会社ドワンゴ は（以下、ドワンゴ）、デジタルテクノロジーによって新たな価値を生み出し続けるエンターテインメント企業です。当社の事業の中でもニコニコ事業は国内有数の動画・生放送配信プラットフォームとして多くのユーザーおよびクリエイターの皆様に愛され、ご利用いただいています。本稿はそんなニコニコ事業における従来のセキュリティ対策に加え、2024年6月初旬に発生したサイバー攻撃を契機に取り組んだセキュリティ改革の概観を紹介するものです。 改革の経緯 ニコニコ事業はインフラストラクチャの大改

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? AWS には Compute Optimizer という、リソースの使用状況などから最適なサイジングなどの推奨事項を提案してくれるサービスがあり、EC2 や Lambda、ECS などのコンピューティングリソースに対応しています。 Compute Optimizer は基本機能だけならば無料で使えて、Organizations のアカウント全体に対して有効にすることができることを知ったので、早速試してみました。 Organizations で Compute Optimizer を全てのアカウントにオプトインする Organizatio

集約すると嬉しいこと VPCエンドポイント自体のコストを大きく削減できるのが一番のポイントですが、 他にもこんなメリットがあると思います。 NAT GatewayやTransit Gatewayへの通信量（≒コスト）が減る場合がある アカウント全体でVPCエンドポイントを作成する回数が1回で済む パブリック/プライベートを意識せずに済む（強制的にプライベートな通信経路となる） などなど コストはどれだけ減るのか 例えば50アカウントで10個のVPCエンドポイント（全て東京リージョン）を利用している場合、 月に $5,110 (¥740,950 $1=¥145）発生します。 これを1つのアカウントに集約すると、 純粋にアカウント数で割ったら月に $102.2(¥14,819 $1=¥145）に下がり、 約98％削減できることになります。 ちなみにVPCエンドポイントは1AZにつき1つ作成する

はじめに 本シリーズでは、Amazon Web Services (AWS) が提供しているAWS Well-Architected Frameworkのハイブリッドネットワーキングレンズを取り上げ、実際にどのような観点でチェックすべきか、そのポイントを前編と後編の2回にわたってご紹介します。本記事では、後編の信頼性、パフォーマンス効率、コスト最適化のチェックポイントについてご紹介します。 AWS Well-Architected Frameworkおよびハイブリッドネットワーキングレンズの概要については、前編の記事をご覧下さい。 本記事で得られるメリット ハイブリッドネットワーキングレンズは関連する追加のベストプラクティスが提供されていますが、「どのような時に何をすればよいか」が一目で分かりづらいことがあります。そこで、本記事はベストプラクティスをシンプルかつ明解なチェックポイントに要約

そのバックアップ、ちゃんと活用できているか不安だな こんにちは、のんピ(@non____97)です。 皆さんは「そのバックアップ、ちゃんと活用できているか不安だな」と感じたことはありますか? 私はあります。 とりあえずバックアップだけ取っているという環境はよくあると思います。そのようなバックアップはコストだけかかっており、トラブル時に実際に役立つものとは限りません。 それでは非常にもったいないです。 ということで、バックアップやDRを計画する際に意識するべきことをまとめてみます。 自分の中でも普段バックアップやDRを計画する際に意識していることは言語化できていなかったので、整理する意味合いでもまとめました。 計画フェーズ バックアップやDRをする目的の設定 まずは、バックアップやDRをする目的の設定をしましょう。 この目的を設定することが一番重要です。 一般的にバックアップやDRは、データ

はじめに Amazon Web Services (AWS) が提供するAWS Well-Architected Frameworkは、AWSアーキテクチャを評価するためのベストプラクティスとして広く知られています。このフレームワークをベースとし、特定の業界やテクノロジー領域に特化した観点を提供するレンズがあることをご存じでしょうか。 本シリーズでは、ハイブリッドネットワーキングレンズを取り上げ、実際にどのような観点でチェックすべきか、そのポイントを前編と後編の2回にわたってご紹介します。本記事では、前編のオペレーショナルエクセレンス、セキュリティのチェックポイントについてご紹介します。 AWS Well-Architected Framework AWS Well-Architected Frameworkは、アーキテクチャを評価するためのベストプラクティスを提供しています。オペレーショ

はじめに 先日、AWS（Amazon Web Services） 主催の「AWS Application Networking Roadshow Japan 2025」というイベントに参加し、VPC LatticeについてDive Deepしました。 KeyNoteでAWSのNetworkingサービスの変遷から、今後VPC Latticeが担っていく役割について学び SAさんのセッションではVPC LatticeとPrivateLinkの統合や EKS、ECSのコンテナワークロードのコンポーネントをどうLatticeが担うかを学び 午後はハンズオンで実際に手を動かす といろいろな角度からVPC Latticeを学ぶことができ、非常に有意義なイベントでした。 参加前までなんとなくとっつきにくかったVPC Latticeの解像度が上がった気がするので、ラップアップを兼ねて執筆に至りました。

４月14日・４月21日・４月28日週振り返り_雑記【デジタル庁公開資料「先行団体の事例から得られた移行作業における留意事項」を読んだ個人的な所感】 年始早々、色々あり更新が停滞中 デジタル庁公開資料「先行団体の事例から得られた移行作業における留意事項」を読んだ個人的な所感4月17日付でデジタル庁が「先行団体の事例から得られた移行作業に おける留意事項」を公開した。デジタル庁が標準準拠システム移行を推進する地方自治体に実施する支援策の１つに先行団体の横展開があり、この点はデジタル庁が行う支援策として必要に意義があり重要なものだと理解している。 本件資料の留意事項全体に「生々しい」情報があり、重要な示唆・重要性を再認識した観点があった。特に気になった主要な点３つを以下に記載した。 １つ目は情報システム部門から業務およびシステム所管部門に対するより強いグリップの必要性である。地方自治体の２０業務

Introduction 以前、こちらの記事で書いたMountpoint for Amazon S3＋IAM Roles Anywhere＋Site to Site VPNを用いてオンプレミスのサーバから「エンドポイント」でマウントをするのを目的に成功した備忘録になります。 今回で使ったもの AWSサービス VPC S3 Endpoint(Interface/Gateway) IAM IAM Roles Anyware Site to Site VPN Security Group AWS Private Certificate Authority Route 53 Inbound Resolver Endpoint Cloudshell (設定に利用します） EC2(通信確認用） オンプレミスの環境 VMWare上に建てているUbuntu最新安定版DesktopEdition　※AWSC

はじめに Route53 Profilesで共有するリソースにVPCエンドポイントが追加されました！ 先日、以下の記事にてマルチアカウントにおけるRoute53で使える便利なサービスとしてRoute53 Profilesを紹介しました。 VPC Endpointを別のVPCで共有するのはちょっと大変だったこれは嬉しいアップデートです。 本記事では従来のプロセスを示したうえで、Route53 Profilesを使うとどのようにしてVPCエンドポイントを共有することができるか実際に構築してみます。 従来の方法 Interface型のVPCエンドポイントはDNSによって、各サービス宛のトラフィックをVPCエンドポイントに向けることで、PrivateLink経由でサービスのAPIにアクセスします。 トラフィックは以下のようなイメージです。 クライアントからRoute53 Resolver→Priv

米オラクルのクラウドサービス「Oracle Cloud Infrastructure（OCI）」にログインする際のSSO（シングルサインオン）サーバーが脅威アクターに攻撃され、約600万件の認証情報が窃取された疑惑が出ている。

他にもIPv4で個別に規定されたアドレス帯や、IPv6でも個別に規定されたアドレス帯がありますが本コラムでは省略します。 MACアドレスの考え方 MACアドレスは、ネットワークインターフェースを識別するために使用される識別子で、Ethernetでは48ビットで表現され、前半32bitがベンダーID、次の8bitが機器ID、最後の16bitがシリアルIDとなることが一般的ですが、例外もあります。過去にはすべての機器が一意に識別されるという説明もありましたが、現在ではこれも例外があります。ネットワークインターフェースごとにMACアドレスを持つため、複数のMACアドレスを持つ機器もあります。 同一ネットワークの通信の仕組み では、IPアドレスとMACアドレスを利用してどのように通信を行うかをおさらいしていきます。 同一ネットワークを192.168.0.0/24として送信元192.168.0.1と

WSLのインストール WSLのインストールはWindows 10 バージョン2004以上またはWindows 11の環境で実施します。Powershellを管理者権限で開き、下記のコマンドを実行します。 wsl --install WSL のインストール | Microsoft Learn 無事WSLがインストールできたらWSLの仮想環境にログインします。 wsl ~ Amazon Q Developer for CLIのインストール WSLの各コンポーネントを最新化します。 $ sudo apt update $ sudo apt upgrade AWS CLIをインストールします。 $ curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip" $ sudo apt install

AWS announces the general availability of VPC Route Server to simplify dynamic routing between virtual appliances in your Amazon VPC. Route Server allows you to advertise routing information through Border Gateway Protocol (BGP) from virtual appliances and dynamically update the VPC route tables associated with subnets and internet gateway. Prior to this feature, you had to create custom scripts o

TL;DR 東京リージョンを利用する際に2AZの冗長化で良い場合のAZ選定 「apne1-az1, apne1-az2」の組み合わせで利用するのが、レイテンシ観点からは良い。 レイテンシ: 500μs程度 大阪リージョンを利用する際に2AZの冗長化で良い場合のAZ選定 「apne3-az1, apne3-az2」の組み合わせで利用するのが、レイテンシ観点からは良い。 レイテンシ: 200μs程度 東京リージョン/大阪リージョンを利用する際にAZの冗長化不要時のAZ選定 どのAZを選定しても、レイテンシの観点からは良い。 レイテンシ: 50μs程度 東京リージョンの方がAZ間レイテンシが平均的に高い(大阪リージョンと比較して) 大阪リージョンの方がAZ間レイテンシが平均的に低い(東京リージョンと比較して) 2024年測定時と比較した際の変化 参考: 2024年に測定した際の記事リンク(Zen

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? ガバメントクラウド上の標準準拠システム同士がデータ連携する方法は、オブジェクトストレージを使ったファイル連携とされてます。AWS ではオブジェクトストレージとして S3 が使われることから、インターネットへ接続できない閉域の VPC 間で S3 のエンドポイントを使うアクセス方法について検証し、次のようなブログ記事を以前書きました。 AWS の VPC 間であれば、閉域であったとしても、EC2 などの AWS リソースから S3 のエンドポイントへアクセスすることは容易です。 一方、閉域で接続されているオンプレミスと VPC の間で、オ

はじめに 登壇内容 セキュリティ・ガバナンス運用の課題 セキュリティ運用の自動化例 FW系リソースの自動更新 AWSサービスのみで作成する完全自動化パターン チャットツール起点とした自動化パターン AWSサービスのみで作成する自動化パターン 更新したFWはどのように管理するのか GuardDuty Malware Protection for S3を最大限活用するための自動化 Configを活用した自動修復機能とそのポイント ケース1：とにかく堅牢な環境を作成する ケース2：コストが増加しにくい環境を作成する ケース3：マルチアカウント環境で運用 まとめ はじめに こんにちは、大林です。2025年3月1日に開催されたJAWS DAYS 2025 に「AWSアカウントのセキュリティ自動化、どこまで進める？　最適な設計と実践ポイント」というタイトルで登壇してきました。聴講してくださった方々、本

Cisco Talos は、早ければ 2025 年 1 月から行われている、主に日本の組織を標的とした攻撃を発見しました。攻撃者の正体は不明です。 攻撃者は Windows の PHP の PHP-CGI 実装におけるリモートコード実行（RCE）の脆弱性（CVE-2024-4577）をエクスプロイトし、被害マシンへの初期アクセスを取得します。 攻撃者は「TaoWu」（一般に入手可能な Cobalt Strike キット）のプラグインをエクスプロイト後の活動で使用します。 Talos は、Alibaba Cloud Container Registry でホストされているコマンドアンドコントロール（C2）サーバー上に、事前設定済みのインストーラスクリプトを発見しました。このスクリプトは攻撃ツールや攻撃フレームワーク一式を展開することから、攻撃者が不正な目的でこれらのツールを悪用している可能性

Amazon Web Services ブログ AWS PrivateLink クロスリージョン接続の導入 概要 AWS PrivateLink は、複数の VPC やアカウント間でサービスを安全かつ簡単に共有・アクセスする方法を提供します。すべてのトラフィックはパブリックインターネットを経由せずに AWS ネットワーク上に留まります。これまで、プロバイダーとコンシューマーは同じ AWS リージョン内に存在する必要がありましたが、AWS PrivateLink のネイティブなクロスリージョン接続のサポート開始により、異なるリージョン間で VPC エンドポイントサービスを共有・アクセスできるようになりました。これにより、サービスプロバイダーは単一のリージョンから世界中の顧客に SaaS ソリューションをプライベートに提供できるようになります。コンシューマーは、同一リージョン内のサービスと同じ