はじめに こんにちは、エンジニアリングマネージャーの芦川です。なぜ基幹システムを担当している自分がこんな話をするのか。単純に、一度話してみたかったからです。 ニフティのコーポレートメッセージ にある「お客様起点」とは、結局のところ何なのか。プロダクトマネジメントを学ぶ中で、ずっとこの問いが根底にありました。AIとの協働開発が広がり、開発のスピードは上がっているのに、それが直接的な成果につながらないという声を色々な会社から聞くようになった今だからこそ、この考え方はより一層大事になってきていると感じています。 書いてみた後の感想ですが、読み返すと中身自体はいたって普通のことでした。ただ、目線を合わせるために、あえて少し強調するように書いています。 まずはプロダクト思考とよく対比される「受託開発思考」をみてみます。 受託開発思考とは何か クライアントや企画職が要件を考え、開発職がその要件をそのまま作る。一見どこにでもある普通の進め方に見えますね。ですが、これには明確なメリットとデメリットがあります。（プロジェクト思考と呼ばれることもあります）。 受託開発思考のメリデメ まずはメリットから。お客様に提供する仕様を計画当初から変えたくない場合、ソフトウェアのEOL対応やレガシー環境からの環境移行などやるべきことがはっきり分かっている場合、受託開発思考が適したケースは確かに存在します。 しかし、すべての開発案件にこの考え方を当てはめてしまうと、「要件通りに作ったのに価値が出ない、売れない」「お客様のために作ったのに使われない」といった、プロダクトアウトな状態に陥ることがよくあります。 そのサービスや機能は、リリースしてみないと使われるかどうか、売れるかどうかわからないものになっていませんか。これからお客様になる誰かが、お金を払ってでもそれが欲しいと言ったことはあるでしょうか。 さらにAIとの協働開発が進むと、開発側のループはどんどん速くなっていきます。けれど、提供する価値がそもそも求められていないものであれば、売れないものを増やすだけになってしまいます。開発生産性は上がっても、価値生産性は上がらない。アウトプット（結果）は増えても、アウトカム（成果）は増えないということです。 アジャイルにより動くソフトウェアを早くリリースしよう、と躍起になるだけでも同じことが言えます。 プロダクト思考になろう そのために基本的には、企画・営業・開発みんなが、それぞれプロダクト思考を持つ必要があるという話です。 企画者は市場やお客様の声を、開発者は実装の実現可能性やログ・データから見える利用実態を、それぞれ異なる立場から持ち寄っています。どちらか一方が持っている情報だけでは、お客様のために「なぜそれを作るのか（Why）」を十分に解像度高く描くことはできません。 だからこそ、企画がエンジニアの領域に越境してみる、エンジニアが企画の領域に越境してみる。双方が互いのフィールドに越境し合うことで、初めてWhyの解像度が上がっていきます 。ニフティのような自社に企画職も内製ができるエンジニアもいる意味は、まさにここにあります。 「お客様のこの課題解決、一緒に考えさせてください」「一緒にやりましょう」。そう言えるようになるには、お客様との接点や対話を通じて、どんな価値から対価が得られるのかを理解することが欠かせません。いま手元にあるお客様へ直接価値提供をするためのプロダクトバックログは、お客様の声を起点にしたものになっているでしょうか。 プロダクト思考とは、ユーザーの課題を深く理解し、解決策であるプロダクトを通じて「価値」を提供し、最大化しようとする考え方です。 そもそも「価値」とは何か ではそもそも価値ってなんでしょうか？機能はイコール価値ではありません。お客様にただリリースしただけでは、それは単なるアウトプットであり、価値ではないのです。お客様の体験が変わり、最終的に対価が得られて初めて、提供価値が生まれます。 どれだけ技術的に優れた、革新的なプロダクトを作ったとしても、事業価値につながらなければ意味がありません。マーケティングと掛け合わせてお客様に届け、実際に使われ、お客様の課題を解決し、お客様がそう感じ、最終的に対価を得られること。ここまでいって初めて、会社としての意味があります。 そもそも「プロダクト」とは何か プロダクトとはお客様体験そのものであり、機能やUI、コンテンツ、決済機能なども含まれます。お客様に何かを提供し、お客様体験に影響を与えるものすべてがプロダクトです。システムとプロダクトは同じではありません。 セールス、UI、機能・コンテンツ、ログイン、サポート、課金。お客様からすればこれらは地続きの一つの体験であり、プロダクト思考の上では分けて考える意味はありません。代理店経由の販路や電話でのアウトバウンドといったセールスの機能も、お客様体験の一部です。 そもそも「お客様体験」とは何か お客様体験には、他社の存在や、自社が直接関与していないリアルな体験まで含まれます。例えばECであれば、他社を含めた商品選びの段階からすでにお客様体験は始まっています。 インターネット回線で言えば、申し込み後の工事日程の調整や、ルーターの設置、設定方法がわからず家族に聞くといった、自社から一旦離れたリアルな行動もすべてお客様体験です。つまり、その出来事に関連してお客様が経験したすべてのことを指します。 ※文脈によって価値やプロダクトやお客様体験については意見が分かれるところがあると思いますが、今回の記事ではこのような位置づけで進めていきます。 社内システムやプラットフォームチームにも通じる話 プロダクト思考は、お客様と直接接点のある事業だけの話ではありません。社内担当者や基幹システムのようなプラットフォームチームでも同じことが言えます。利用者へのアンケートや個別ヒアリングを行い、組織全体の最適化を考える。ここでも、なぜそれを作るのかを対話を通じて理解し、利用者体験の現状を把握し、これから体験をどう良く変えていくか想像することが欠かせません。 さて、プロダクト思考についてはなんとなくわかりました。が、実際、プロダクト思考を持つエンジニアは、これから何をしていけばよいのでしょうか？ 明日からできる3つの行動 ① 越境を意識するコミュニケーション ビジネス側、開発側、CS、営業がそれぞれの領域を越えて理解を深めなければ、会社として良い仕事はできません。複数の業務や複数のシステムが横断して一つの価値提供につながっている場合、自分の担当範囲に仕事を閉じず、他チームに越境してコミュニケーションを取ることが大切です。部署を越えたプロダクトマネジメントの輪読会のような場は、立場の違う意見が交わされる貴重な機会になります。 ② いまあるものを理解する、お客様や業務ドメイン知識 長い歴史と多くの会員を抱えていることは、大きな強みです。自社のサービスや構造を知り、業務ドメインを理解する。既存のお客様がどこに価値を感じ、対価を支払ってくれているのかを理解する。歴史が長いということは、過去の失敗も多く積み重なっているということでもあります。 ただし、問い合わせをしてくるお客様はごく一部に過ぎず、その声だけが全体を代表しているわけではないという点には注意が必要です。データ分析やAIによる分析なども積極的に活用していきたいところです。 ③ いまないものを学ぶ、ニフティにはまだまだお客様との対話が必要 足りていないお客様との接点を増やすこと。お客様に直接インタビューを行い、他社を含めたリアルな行動や感情について聞いてみる。お金を払ってでも解決したいことは何かを、直接尋ねてみる。自分自身でサービスを利用し、お客様体験を学ぶことも欠かせません。 ここで注意したいのが確証バイアスです。「こういう機能があったらいいと思いますか」と聞いて「あったらいいかも」と答えられても、実際には「自分は使わないけれど誰かは使うかも」という温度感であることが多く、結果として使われない、買われないという事態につながります。拾えていない声や感情、体験にこそ、学ぶべきものがあります。 まとめ 受託開発思考は、依頼された仕様を正確に作るというスタンスで、スケジュール通りに納品し、開発生産性を上げることを重視します。要件が明確で進めやすく、納品という区切りがつけやすい一方、作ることがゴールになりがちであり、お客様への意識が弱くなりやすく、担当範囲の壁を越えにくくなるという側面もあります。 プロダクト思考は、提供価値を理解しユーザー課題を解決するために作るというスタンスで、なぜそれを作るのかを問い続け、価値生産性を上げることを重視します。ユーザー価値に直結した開発ができ、お客様体験の理解が深まり、企画と開発のゴールが一致しやすくなります。一方で、最初から正解が存在するわけではなく、お客様の求めるものを深掘りするには時間がかかります。また終わりはありません。 おわりに ニフティグループは、お客様、株主、社員、パートナー企業、地域社会などの夢をかなえるため、常にお客様起点で行動し、チャレンジャーとしてサービスを開拓し、社会に役立つ企業として新しい価値の創造に取り組み続けます。 このコーポレートメッセージは、まさにプロダクト思考そのものだと思っています。書いてみて改めて感じたのは、至極当たり前のことを、目線合わせのために言語化しただけだということです。それでも、こうして言葉にしてみることに意味があると信じています。

本ブログは 2026 年 7 月 14 日に公開された AWS Blog “ Security Hub adds AI workload protection and multicloud support for Microsoft Azure ” を翻訳したものです。 AWS Security Hub は、クラウドをまたぐフルスタックのエンタープライズセキュリティの基盤です。セキュリティ運用を一元化し、生のシグナルを優先順位付けされたインサイトに変換することで、チームはツールをつなぎ合わせる作業ではなく、実際のリスク管理に時間を使えるようになります。本日 (2026 年 7 月 14 日)、この基盤は、お客様から最も多くの要望をいただいた 2 つの方向に拡張されます。AI ワークロード専用の保護機能と、Microsoft Azure を対象としたセキュリティモニタリングの追加です。どちらも、優れたセキュリティツールは連携することでより賢くなるべきである、という大きな構想に向けた一歩です。 これらの拡張はお客様の声から直接生まれたものであり、セキュリティの過去ではなく、これから向かう先を反映しています。従来のセキュリティツールが約束していたのは、すべてを 1 つのビューに集約する場所でした。しかし、検出結果を集めること自体は難しい部分ではありません。難しいのは、それらを理解し、関連付け、攻撃者よりも先に行動すること、しかも現在の攻撃のスピードに合わせてそれを行うことです。これから成功するセキュリティプログラムは、最も多くのダッシュボードを持つものではなく、環境全体を見渡し、迅速に対応できるものです。それこそが AWS の目指すものであり、今回のリリースはその道のりの一歩です。 Microsoft Azure に対応するマルチクラウドセキュリティ管理 さまざまな業界のお客様が、AWS でのセキュリティ運用の中核として Security Hub を活用しています。その多くは何年も前から複数のクラウドを運用しており、Security Hub でセキュリティ環境の残りの領域もカバーしてほしいという明確な要望をいただいていました。本日、Microsoft Azure に対応し、他のクラウドにも順次対応していきます。 Security Hub は今回、Azure Virtual Machines、コンテナイメージ、Function Apps、アイデンティティを検出し、設定不備、インターネットへの露出、ソフトウェアの脆弱性を評価できるようになりました。また、CIS Microsoft Azure Foundations Benchmark に基づくポスチャチェックも行います。Azure の検出結果は、同じ検出結果フォーマット、自動化、対応ワークフローを使用して AWS の検出結果と並べて優先順位付けされるため、チームはセキュリティ環境全体にわたるリスクを 1 つの視点で把握しながら作業できます。Azure リソースの料金は、同等の AWS リソースと同じ料金体系で、追加料金はありません。また、Azure の監視には別枠で 30 日間の無料トライアルが用意されています。詳細については、 What’s New の投稿 を参照してください。 実は、AWS 以外への拡張はこれが初めてではありません。今年の初めに、 Security Hub Extended を発表し、9 つのセキュリティカテゴリにわたるベストインクラスのパートナーソリューションを、既にお使いのエクスペリエンスに統合しました。これらのパートナーソリューションは、あらゆるクラウド、オンプレミス、企業が事業を展開するあらゆる場所で、エンドポイント、アイデンティティ、E メール、ブラウザ、データを保護します。Extended は既に、マルチクラウドとマルチワークロードに向けた最初の一歩となっていました。本日、AWS 独自のネイティブ機能がカバーする範囲を広げ、この 2 つの取り組みは今後歩調を合わせて進化していきます。 AI ワークロードの保護 私がお話しするどのお客様も、AI を活用した構築を進めています。Amazon Bedrock での生成 AI、Amazon SageMaker でのモデルトレーニング、Bedrock AgentCore を通じてワークフローをオーケストレーションするエージェントなどです。これらのワークロードは、多くのセキュリティプログラムが追いつけないスピードで本番環境に到達しています。しかも、モデルの呼び出しをモニタリングしたり、エージェントの動作を追跡したり、組織全体にどのような AI 資産が存在するかを把握したりするツールを、チームがまだ持っていないことも少なくありません。あるセキュリティリーダーは、基盤モデルを何千回も呼び出していた侵害されたサービスアカウントに気づけたのは、経理部門が請求書に疑問を持ったからだと話してくれました。会計レビューを通じてセキュリティインシデントが発見されたのです。可視性のギャップは現実に存在し、既に高い代償を生んでいます。 この夏、AWS は 3 つのリリースでこのギャップを埋め始めます。2 つは脅威検出と調査のための GuardDuty の機能、3 つ目は新しい Security Hub AI inventory (AI インベントリ) です。 GuardDuty AI Protection (一般提供開始) Amazon GuardDuty AI Protection は、Amazon Bedrock と SageMaker 専用に構築された脅威検出を提供します。異常なモデル呼び出し、コストハーベスティング (盗んだ認証情報を悪用して推論を実行させ、お客様に費用を負担させる攻撃)、そして Amazon Bedrock Guardrails との統合によるプロンプトインジェクションの試みを検出します。 コストハーベスティングは急増しています。認証情報が侵害されると、攻撃者はそれを使って基盤モデルを呼び出すケースが増えています。推論は高コストで需要も高いため、盗んだアクセス権は、インフラストラクチャを一切デプロイすることなく、そのまま価値に変換できてしまうのです。GuardDuty は AWS CloudTrail のデータイベントを分析し、大規模な環境で正常な呼び出しがどのようなものかを学習し、侵害や悪用を示す逸脱を検出します。これは AWS の規模だからこそ実現できる検出です。何が正常かを知るには、何百万ものワークロードにわたるシグナルを見る必要があるからです。GuardDuty AI Protection は、30 日間の無料トライアル付きで、すべての GuardDuty のお客様が利用できるようになりました。 GuardDuty AI-powered investigations (プレビュー) AI を活用した調査 (AI-powered investigations) は、アラート疲れを引き起こし、対応を遅らせる要因となっていた手動の調査作業を引き受けます。この機能は、GuardDuty の検出結果とその周辺のアカウントを自動的に分析し、真の脅威と無害なアクティビティを切り分けます。 検出結果のコンテキスト、過去 90 日間の関連アクティビティ、影響を受けたリソース、脅威インジケーターを調査し、ナレッジグラフと脅威インテリジェンスを使用して、これまで数時間かかっていた作業を数分で完了します。各調査では、信頼度スコアを伴う判定評価、MITRE ATT&CK® 分類、裏付けとなる証拠、そして抑制、封じ込め、または修復のための明確な推奨事項が得られます。チームは、単一のアカウントでも AWS Organizations の組織全体でも、本物の脅威に集中でき、平均解決時間が短縮されます。GuardDuty AI-powered investigations は、10 の AWS リージョンでプレビューとして利用可能です。 Security Hub AI inventory (一般提供開始) 存在を知らないものを保護することはできません。Security Hub では、AI 資産とそのセキュリティポスチャを組織全体で継続的に最新の状態で確認できる AI インベントリ が利用できるようになりました。チームがモデル、エージェント、パイプラインをデプロイしても、セキュリティ部門は何が動いているのかを把握できないことが多く、それらの資産をアクティブな脅威や設定不備と関連付けなければ、何を最初に保護すべきかを判断するのは困難です。 Security Hub AI inventory は、AWS 環境全体の AI ワークロードを 2 つの方法で検出してカタログ化します。マネージドサービスについては、Amazon Bedrock、SageMaker、Bedrock AgentCore のリソースを AWS Config 経由でインベントリ化します。セルフホストおよび外部のワークロードについては、ランタイム分析を通じて Amazon EC2、Amazon ECS、Amazon EKS 上で実行されているモデルを発見し、ワークロードが呼び出している外部モデルのエンドポイントを特定します。各資産を、コンピューティング、ネットワーキング、IAM ロール、データストアなど、その基盤となるインフラストラクチャにマッピングし、GuardDuty の検出結果などのセキュリティシグナルと関連付けます。そのため、GuardDuty AI Protection が異常な呼び出しを検出すると、AI インベントリはどのインフラストラクチャが関与しているか、何がそれに接続されているか、優先順位のどこに位置するかを即時に表示します。 AI 資産は急速に増えていきます。ある開発者が概念実証のために Amazon Bedrock エージェントを立ち上げます。データサイエンスチームが内部テスト用に SageMaker エンドポイントを構築します。別のチームは AWS Lambda 関数を通じて外部モデル API を組み込みます。これが数百、数千のアカウントで起これば、すぐに把握しきれなくなります。AI インベントリは、組織内のすべてのアカウントを横断したビューを提供します。この機能は Security Hub エッセンシャルプランで追加料金なしで利用できます。 フルスタックセキュリティへの新たなアプローチ これらのリリースには、注目に値する共通点があります。AI 保護を別製品として調達する必要はなく、Azure 用に別の運用体制を立ち上げる必要もありません。既に運用している Security Hub にそれらを追加するだけで、優先順位付けされたリスクのビューに表示されます。この同じ考え方を、セキュリティ環境の残りの領域にまで広げるのが Security Hub Extended です。 Security Hub Extended には現在、9 つのカテゴリにわたる 21 のキュレーションされたパートナーが参加しています。 7AI 、 Britive 、 CrowdStrike 、 Idira (CyberArk) 、 Cyera 、 Island 、 LayerX 、 Native Security 、 Noma 、 Okta 、 Oligo 、 Opti 、 Proofpoint 、 SailPoint 、 SentinelOne 、 Splunk 、 Sublime 、 Upwind 、 Varonis 、 Zenity 、 Zscaler です。これらは、エンドポイント、アイデンティティ、E メール、ネットワーク、データ、ブラウザ、クラウド、AI、セキュリティ運用にわたるベストインクラスのソリューションです。どのパートナーも、無条件に選ばれたわけではありません。それぞれが、エンタープライズセキュリティの向かう先についての共通のビジョンにコミットし、AWS とともにそれを構築するために投資することで、その地位を獲得しました。キュレーションこそが重要なのです。選ばれないという結果があり得るからこそ、推奨には意味があります。 Extended のビジネス面のメリットは今すぐ得られます。従量制料金、AWS への一本化された請求、EDP (Enterprise Discount Program) の適用対象であること、長期契約が不要であることです。しかし、AWS が最も力を入れている取り組みはその先にあり、調達の話ではまったくありません。参加しているすべてのソリューションの検出結果は Open Cybersecurity Schema Framework (OCSF) 形式で出力され、Security Hub に集約されます。AWS は、それらすべてを横断する単一の相関分析の実現に取り組んでいます。これにより、エンドポイントソリューション、アイデンティティソリューション、クラウドソリューションからのシグナルが、3 つのばらばらのアラートではなく、1 つのエクスポージャーと 1 つの攻撃パスとして統合されます。また、サブスクリプション登録から価値を実感するまでのデプロイとオンボーディングの手間を減らす取り組みも進めています。さらに、パートナーの検出結果が互いを強化し合う仕組みを構築しており、既に信頼しているベストインクラスのツールが、単独で使うとき以上の価値を発揮するようになります。これが、AWS が投資している差別化された未来であり、お客様の次の要望に導かれながら、オープンに構築を進めています。Extended の詳細については、 What’s New の投稿 を参照してください。 さらなる前進へ 一歩引いて見れば、全体像は明確です。Security Hub は、Azure を皮切りにクラウドプロバイダーを横断して拡大していきます。専用の AI 保護とインベントリにより、ワークロードタイプを横断します。そして、Extended とキュレーションされたパートナーを通じて、セキュリティカテゴリを横断します。AWS のセキュリティ検出結果を整理する手段として始まったものが、より多くの企業がフルスタックセキュリティを運用する方法へと発展しました。 検出と可視性が土台となります。その上に AWS が構築するのは、信頼するすべてのソースからのシグナルをつなぎ、より迅速な対応を支援するセキュリティエクスペリエンスです。まだ Day 1 であり、お客様の環境と直面する脅威が変化し続ける中、Security Hub は拡張を続けていきます。 Michael Fuller Michael は AWS に 16 年間在籍し、11 年間にわたり AWS セキュリティサービスのプロダクトを率いてきました。業界歴は 29 年で、IBM、Cisco、Amazon においてプロダクトマネジメント、ビジネス開発、ソフトウェア開発のさまざまな役割を務めてきました。アリゾナ大学でコンピュータエンジニアリングの理学士号を、ワシントン大学で MBA を取得しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本記事は 2026 年 6 月 30 日 に公開された「 Enable self-managed AD Kerberos authentication with Amazon RDS for Db2 」を翻訳したものです。 Amazon Relational Database Service (Amazon RDS) for Db2 は、AWS、オンプレミス、他のクラウドのいずれで稼働している場合でも、お客様自身の Active Directory ドメインを利用した Kerberos 認証をサポートしています。Amazon RDS for Db2 をお客様が管理する Microsoft Active Directory に直接接続することで、データベースユーザーの認証を一元化し、シングルサインオンを実現できます。この構成の要となるのは、正確に絞り込んだ一連の AD 権限を専用のサービスアカウントに委任し、その認証情報を RDS へ安全に受け渡すことです。 本記事では、Amazon RDS for Db2 向けに Windows Active Directory を Kerberos 認証で構成する方法と、ドメイン参加済みのクライアントから構成を検証する方法を紹介します。 aws-samples/sample-rds-db2-tools リポジトリで公開されている一連の手順を、最初から最後まで順を追って説明します。 専用の OU とサービスアカウントを作成する。 Amazon RDS for Db2 が AD と連携するために必要な AD 権限を委任する。 認証情報を AWS Key Management Service (AWS KMS) で暗号化したシークレットとして AWS Secrets Manager に保存する。 生の GUID を人間が読める権限名に変換する PowerShell スクリプトで構成を検証する。 続いて、ドメイン参加済みの Db2 クライアントから構成を検証する方法を紹介します。 EC2 インスタンスを起動する。 インスタンスをドメインに参加させる。 Db2 Runtime Client をインストールする。 Kerberos チケットで接続する (パスワード不要)。 さらに、多くの人がつまずく分かりにくいステップも 1 つ取り上げます。User オブジェクトに対して servicePrincipalName の読み取り/書き込み権限を付与するには、標準の Active Directory ユーザーとコンピューター スナップインではなく、ADSI エディター ( adsiedit.msc ) が必要です。 ソリューションの概要 次の図は、お客様が管理する Active Directory に対して Amazon RDS for Db2 を認証する際のアーキテクチャを示しています。 この設計では、RDS for Db2 がお客様のセルフマネージド AD ドメインに直接参加します。専用の AD サービスアカウントのユーザー ID とパスワードは AWS Secrets Manager に保存され、AWS KMS キーで暗号化されます。ドメイン参加の際、RDS はこれらの認証情報を Secrets Manager から取得し、ディレクトリにインスタンスを登録します。ドメイン参加済みの Db2 クライアントは AD の KDC から Kerberos チケット (TGT) を取得し、そのチケットを使ってパスワードのやり取りなしに RDS for Db2 へ接続します。RDS、クライアント、ドメインコントローラー間の通信は、標準的な AD のポート、すなわち DNS (53)、Kerberos (88、464)、LDAP (389、3268)、RPC 動的範囲 (49152〜65535) を利用します。 構築するもの RDS for Db2 用に範囲を絞った専用の OU と AD サービスアカウント、および RDS for Db2 が必要とする権限を委任した ACL。 認証情報を RDS へ安全に受け渡すための AWS KMS キーと Secrets Manager シークレット。 セルフマネージド AD 変数を設定した Amazon RDS for Db2 インスタンス。 AL2023 の EC2 ドメイン参加済みクライアントを使ってテスト済みの接続。 1. AD 権限を委任する 専用の OU とサービスアカウントを作成し、[制御の委任] ウィザードと ADSI エディターを使って必要なアクセス制御エントリ (ACE) を付与します。 OU 内で User オブジェクトと Computer オブジェクトを作成/削除する。 子孫の User オブジェクトに対して、パスワードのリセットと msDS-SupportedEncryptionTypes の読み取り/書き込みを行う ([制御の委任] ウィザードを使用)。 子孫の User オブジェクトに対して servicePrincipalName の読み取り/書き込みを行う — ADSI エディターを使用 ( adsiedit.msc )。 あるいは、提供されている PowerShell スクリプト を実行すれば、9 つの ACE すべてを冪等な 1 回の処理で適用できます。 .\Grant-ADDomainJoinPrivileges.ps1 ` -ServiceAccount "CORP\rdsdb2svc" ` -TargetOU "OU=RDSDb2,DC=company,DC=com" ` -Verbose 同梱の、人間が読める形式で表示する ACL ビューアー スクリプトで検証します。 .\Show-OUDelegation.ps1 -OU "OU=RDSDb2,DC=company,DC=com" -SamAccountName rdsdb2svc ServiceAccount 名はお好みの名前に置き換えるか、 rdsdb2svc のままにします。 TargetOU では、OU 名をお好みの名前に変更するか RDSDb2 のままにできますが、DC 名は必ずお使いの AD のドメイン名に合わせて変更してください。例: "OU=RDSDb2,DC=corp,DC=mycompany,DC=com" 。 リポジトリでは、この委任について 2 つの同等な方法を説明しています。ADUC の [制御の委任] ウィザードと ADSI エディターを使う UI での手順と、上記の PowerShell スクリプトです。どちらも同じ ACL を生成するため、運用モデルに合った方を選んでください。始める前に、 リポジトリの README を読んで一連の手順の全体像を把握してから、委任そのものについては詳細な UI での手順 (または PowerShell ガイド ) に従ってください。 リポジトリの詳細な手順: README-UI.md 2. KMS キーと Secrets Manager シークレットを作成する 対称 KMS キーを作成し、サービスアカウントの認証情報を Secrets Manager シークレットとして保存します。このとき、RDS が読み取れるようにするリソースポリシーを設定します。 aws kms create-key --key-usage ENCRYPT_DECRYPT --key-spec SYMMETRIC_DEFAULT ... aws secretsmanager create-secret --name "rds-db2-self-managed-ad-secret" ... リポジトリの詳細な手順: README-KMS-Secret.md 3. サービスアカウントの認証情報を AWS Secrets Manager に保存する AD サービスアカウントのユーザー名 ( sAMAccountName のみで、 DOMAIN\ プレフィックスは付けない) とパスワードを、前のステップで作成した KMS キーで暗号化した Secrets Manager シークレットとして保存し、RDS が読み取れるようにするリソースポリシーをアタッチします。RDS for Db2 は、ドメイン参加の際にこのシークレットを取得します。 aws secretsmanager create-secret --name "rds-db2-self-managed-ad-secret" ... UI と CLI の詳しい手順はリポジトリにあります: README-KMS-Secret.md 4. RDS for Db2 インスタンスを構成する DB インスタンスを変更または作成し、[ディレクトリ] セクションでシークレットの ARN を指定します。CLI の場合は次のとおりです。 aws rds modify-db-instance \ --db-instance-identifier your-db-instance \ --domain-fqdn "company.com" \ --domain-ou "OU=RDSDb2,DC=company,DC=com" \ --domain-auth-secret-arn "arn:aws:secretsmanager:..." \ --domain-dns-ips "<dc-ip-1>" "<dc-ip-2>" \ ... リポジトリの詳細な手順: README-RDS-Db2.md 5. ドメイン参加済みの Db2 クライアントから接続をテストする 同じ VPC 内で Amazon Linux 2023 の EC2 インスタンスを起動し、AD ドメインに参加させて、Db2 Runtime Client をインストールします。 ステップ 1 – AD に参加する realmd 、 sssd 、 adcli 、 krb5-workstation をインストールします。 curl -sL https://bit.ly/domainjoin | bash source joindomain.sh ステップ 2 – Db2 RT クライアント をインストールする REGION=<region> ./db2-driver.sh ステップ 3 – DSN エントリを構成する ドメイン参加を自動検出し、ローカル認証用と Kerberos 用の両方の DSN を書き込みます。 sudo su - db2inst1 REGION=<region> source db2client-configure.sh ステップ 4 – 接続する kinit user@COMPANY.COM db2 terminate db2 "connect to RDSAKS" # Kerberos, no password db2 "connect to RDSAS user admin using '$MASTER_USER_PASSWORD'" # local auth リポジトリの詳細な手順: README-Db2-Client.md 重要なポイント User オブジェクトの SPN には ADUC ではなく ADSI エディターを使う。 ADUC スナップインは、User オブジェクトの属性一覧から servicePrincipalName を除外して表示します。ADSI エディターはスキーマ全体を表示します。ここが最もよくあるつまずきポイントです。 スコープが重要。 User オブジェクトではなく Computer オブジェクトに SPN の読み取り/書き込みを付与すると、一見正しく見えても実行時に失敗する ACL になります。Amazon RDS for Db2 は、自身が作成する User オブジェクトの権限をチェックするのであって、Computer オブジェクトではありません。 UI ではなく PowerShell で検証する。 ADUC の [セキュリティ] タブは、属性レベルの ACE を空白の行にまとめて表示してしまいます。提供されている Show-OUDelegation.ps1 スクリプトは、GUID を名前に解決して ACL を読みやすくします。 Secrets Manager でのユーザー名の形式。 シークレットには sAMAccountName のみを含める必要があり、 DOMAIN\ プレフィックスは付けません。ドメインプレフィックスを含めると、インスタンスの作成に失敗します。 ネットワーク AD と RDS の間には、複数のネットワーク構成が考えられます。次の 3 つのネットワークトポロジーについては、この ガイド を参照してください。 AD と RDS が同じ VPC 内にある構成。 AD を Microsoft Azure でホストする構成 (VPN または AWS Direct Connect + ExpressRoute)。 AD が別の VPC または AWS アカウントにある構成 (VPC ピアリングまたは AWS Transit Gateway)。 主要なポートは DNS (53)、Kerberos (88、464)、LDAP (389、3268)、RPC 動的ポート (49152〜65535) です。RPC の範囲を開け忘れることが、最初のドメイン参加が成功した後に断続的な障害が起きる最もよくある原因です。 クリーンアップ 継続的な課金を避け、この手順で Active Directory に作成したプリンシパルを削除するには、作成した順序とは逆の順序でリソースを削除します。 EC2 の Db2 クライアントを終了する — ドメインから離脱し (realm leave)、自身のコンピューターオブジェクトを削除してから、インスタンスを終了し、専用の IAM インスタンスプロファイル/ロールがあれば削除します。 RDS for Db2 からセルフマネージド AD を削除する — インスタンスを残す場合は aws rds modify-db-instance --disable-domain でドメインをデタッチして (再起動)、不要になった場合は aws rds delete-db-instance でインスタンスを削除します。 サービスアカウントの認証情報を保持している Secrets Manager シークレットを削除する 。 KMS キーの削除をスケジュールし 、そのエイリアスを削除します。いずれかのインスタンスがストレージ暗号化にそのキーをまだ使用している間はキーを削除しないでください。削除するとスナップショットが復元不能になります。 AD オブジェクトを削除する — サービスアカウントと専用の OU を削除します (RDS がドメイン参加時に作成した Computer/User オブジェクトをすべて消去するため、再帰的に削除します)。OU は残して委任した権限だけを外したい場合は、OU の ACL をリセットします。 これらそれぞれについて、コンソールと CLI のオプションや検証チェックを含む手順ごとのコマンドは、GitHub リポジトリの クリーンアップガイド にあります。 まとめ 本記事では、セルフマネージド Active Directory を使って Amazon RDS for Db2 の Kerberos 認証を有効にする方法を紹介しました。9 つの AD 権限を正確に専用のサービスアカウントに委任し、その認証情報を KMS で暗号化した Secrets Manager シークレットとして RDS へ安全に受け渡し、DB インスタンスをドメインに参加させ、ドメイン参加済みの Db2 クライアントから Kerberos チケットを使ってパスワードなしで接続することで、結果を最初から最後まで検証しました。その過程で、多くの人がつまずきやすいステップも取り上げました。すなわち、 servicePrincipalName の ACE には ADSI エディターを使うこと、権限を User オブジェクトに絞ること、そして RPC の動的ポート範囲を開けることです。 本記事全体で参照した PowerShell スクリプト、CLI コマンド、検証ツールは、 aws-samples/sample-rds-db2-tools GitHub リポジトリで入手できます。リポジトリをクローンし、変数をお使いのドメインに合わせて調整すれば、RDS for Db2 ワークロード向けに一元化されたシングルサインオン認証をすぐに稼働させられます。詳細については、Amazon RDS ユーザーガイドの Kerberos authentication for Amazon RDS for Db2 を参照してください。ご質問やご提案があれば、コメントをお寄せください。 著者について Vikram S Khatri Vikram は、 Vikram は Amazon RDS for Db2 のシニアエンジニアです。プロダクトマネジメント、経験豊富なアーキテクト、リーダーシップ、AI エキスパートユーザーなど、複数の役割を担っています。20 年以上の経験を持ち、ゼロから新しい製品を生み出すことに情熱を注いでいます。 Sindhu Simhadri Sindhu は、 Sindhu は Amazon RDS for Db2 のソフトウェア開発エンジニアです。10 年以上のソフトウェア開発経験を持っています。 Yiwen Shen Yiwen は、 Yiwen は Amazon RDS for Db2 のソフトウェア開発エンジニアです。5 年以上のソフトウェア開発経験を持っています。 この記事はSolutions Architect の 矢木 覚が翻訳しました。