はじめに こんにちは！丹羽と申します。 初めてのブログ投稿です。よろしくお願いします。 今回は私がサイオステクノロジーに入社して1年間で読んだ書籍をご紹介します。 こんな方へおすすめ 入社1年目の新入社員・新人エンジニアの方 IT業界への就職が決まった大学4年生の方 「仕事の進め方」や「文章力」に課題を感じている方 ビジネス書籍 入社1年目の教科書 ワークブック その名の通り、入社1年目の新入社員に向けたビジネス書です。 「優秀な新人」や「モチベーションの高い新人」を目指すものではなく、ビジネスパーソンとして最も重要な「信頼」を得ることを目指します。 抽象的なことではなく、仕事をする上での具体的な仕事術が書いてあります。 この本を「読む」「読まない」では仕事に適応する速度が変わると思います。 ITエンジニア1年目の教科書 新人エンジニアが仕事で成功体験を積み重ね、自分で自信を育てられるように、「優秀な若手エンジニアが自然とやっていること」を言語化した本です。 構成は、テクニカルスキル(第1部)、ヒューマンスキル(第2部)、自己投資スキル(第3部)となっており、スキルごとにまとまっているので読みやすいです。 何回も読み直している本の1つです。 コンサル一年目が学ぶこと テーマが「コンサル一年目が学ぶこと」ですが、職業や業界を問わず、15年、20年とずっと役立つ普遍的なスキルを、基礎的なレベルから学べる本です。 4章構成で、それぞれ、話す技術(第1章)、思考術(第2章)、デスクワーク術(第3章)、ビジネスマインド(第4章)となっています。 特に第1章の、「相手の期待値を把握する」「上司の期待値を超える」という節は、社会人1年目からずっと心がけることの1つだと思いました。 会社では教えてもらえない 上に行く人の報連相のキホン 「報連相」に焦点を当て、「きちんと仕事をこなしているのに評価されない」「仕事が思うように進まない」と悩んでいる新入社員含め若手のビジネスパーソン向けの本です。 基本的に仕事は一人でするものではなく、自分に対して業務の指示と管理をする上司が、仕事の成果の主な評価者です。その上司に対して「報連相」をするタイミング、対応の優先順位を上げてもらう方法など、すぐにでも実践できる具体的なハウツーが書いてあります。 「報連相」は社会人において必須スキルなので、今回紹介するビジネス書籍の中でも最もおすすめしたい書籍の1つです。 ToDoリストですら使えなかった僕が見つけたすごい仕事術 「ToDoリストでタスクを管理せよ」「朝活で時間を有効活用せよ」「やり抜く力を身に付けよ」など、ビジネス書に書かれているような「仕事術」ができなかった、または難しい方向けの本です。 何十人もの部下を見てきた上司に「今までで一番仕事ができない」と言われた筆者が、外注したら2000万円かかると言われていた作業を1人でやり、「仕事ができる」と認められるようになるまでに編み出した仕事術が書かれています。その仕事術とは、「自分の意志」や「頑張り」に頼らず、意志力ゼロでも動く「仕組み」をつくるものです。 「頑張ろうとしても頑張れない」「頑張っているのにミスをしてしまう」といった方におすすめです。 超訳 カーネギー 人を動かす エッセンシャル版 本書は『超訳 カーネギー 人を動かす』を文庫エッセンシャル版として加筆訂正を加えて再編集したもので、職場、学校、家庭で円満な人間関係を築き、大きな成果を出すための、人間関係の原則が書かれた本です。全部で項目が181個ありますが、全て1ページ～2ページで書かれたものなのでサクサク読めます。 「181個も覚えることがあるのか」と思われるかもしれませんが、テーマを変えただけで趣旨が重複しているものが多いので、読むうちに筆者が伝えたいことがわかると思います。 体力がない人の仕事の戦略 体力がない人が根性論に頼らず、限られたエネルギーで成果を出す「燃費の良い働き方」が書かれている本です。仕事をやる上で「今よりラクな方法を探す」重要性を説いています。 特に真面目でいつも全力で頑張ってしまう方、頑張りすぎてガス欠を起こしたことがある方におすすめです。 伝わる文章が「速く」「思い通り」に書ける87の法則 分かりやすい言葉で「伝わる文章」の書き方が87項目にわたって書かれた本です。 本書のノウハウは、企画書・報告書・日報の作成から、論文やレポート、プライベートのチャットのやりとり、ブログやSNSの投稿記事まであらゆる文章に応用できます。 私は仕事上使用するチャットツールの文章が上手く伝わらず悩んでいましたが、この本がとても参考になりました。 エンジニアのための文章術再入門講座 新版 ITエンジニアが業務で必要な文書・文章を書くために「最低限必要な知識、ノウハウ、コツ」を整理した本です。 文章の書き方の基礎技術から、社内への報告や社外への依頼の書き方、相手に配慮した円滑な社内コミュニケーションの方法などが書かれています。 色々な方法が書かれていますが、社内での書き方もあると思うので、この本と併せて普段のチャットやメールから、先輩の書き方を勉強することも大切だと思いました。 IT仕事図鑑 本書は、そもそもIT業界とは何かから始まり、IT業界での働き方、IT仕事の基礎知識、IT職種の説明が書かれた本です。掲載されている職種は64種類と広範囲をカバーしており、この本に載っていないIT職種はほぼ無いと思います。 ITについて網羅的に書かれているので、余裕があれば手元に置いておいてもよいと思います。 技術書籍 リーダブルコード とても有名な、「理解しやすい」＝「優れた」プログラムコードを書くための本です。 最初に悪い例が出され、その後改善例が出されるので理解しやすいです。 個人的に特に印象に残ったのが「条件式には基本的にif/elseを使い、三項演算子を使わない」という項です。 AIにコードを書いてもらうと、1行で書ける条件式は三項演算子になることが多いです。簡潔な条件式なら理解しやすいのですが、複雑な条件式だと途端に理解に時間がかかります。 以前SNSで「三項演算子を使えるようになったら上級者」「三項演算子を使うのがスマートな書き方である」という文言を見かけて、「三項演算子に慣れたら読みやすくなるだろう」「コードの行数は少なければ少ないほどいいのだろう」と思っていました。 なので、上記の項は目から鱗でしたし、SNSの投稿とは違い実例も載っていたので、説得力がありました。SNSの情報を信じるよりも、技術書に載っている情報を信じた方がいい、という教訓にもなりました。 プログラムの基本的な文法を一通り覚えた方におすすめです。 プログラマー脳 本書は、コードリーディングやコーディング時の脳の働きを理解することで、プログラマーとしてのスキルや習慣を向上させる本です。 コードリーディングやコーディング時は、脳のどの機能と関連しているか、その脳の機能をどう補うかについて書かれています。 コードリーディングやコーディングの効率を上げたい方におすすめです。 Webを支える技術 本書は、HTTP、URI、HTMLなど、Webを支える根本的な技術を学べる本です。 「はじめに」の部分で対象読者は「Web技術を使ったシステム開発の経験がある人」と記載がありますが、理解に特別知識や経験が要るものではないです。 また巻末に付録としてステータスコード(404 Not Foundなど)の一覧があります。 この本を読む前は、出てきたステータスコードの意味をその都度調べていたのですが、この本で学んだ後は調べることはほぼ無くなりました。 IT業界に就職予定の方や、新人エンジニアの方におすすめです。 ソフトウェアテストの教科書 本書は、ソフトウェアテストを「実践的で」「わかりやすく」解説した本です。 実際にテストでバグが見つかりやすい箇所から、テストドキュメントの書き方まで幅広く書かれています。 テスト業務を１回でもやったことがあるエンジニアの方におすすめです。 Python ゼロからはじめるプログラミング 本書は、Pythonを学習して使えるようになることに加えて、プログラミングの基礎を習得することにも重点を置いた本です。 Pythonの基礎だけでなく、「プログラムとは何か」ということまで解説してくれます。 ページ数も少なく、簡潔にわかりやすく書かれているので読みやすいです。 ただ、今後色んな言語を学習していくとすると、初めて学ぶプログラミング言語はPython以外が個人的にはおすすめです。 なので、他のプログラミング言語を学習済で、Pythonの基礎を学びたい方におすすめです。 まとめ 今回は、私がサイオステクノロジーに入社して1年間で読んだ書籍をビジネス書・技術書問わずご紹介しました。 何か1冊でも参考になれば幸いです。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 1人がこの投稿は役に立ったと言っています。 The post エンジニア1年目に読んだ書籍をまとめてみた first appeared on SIOS Tech Lab .

本ブログは 2025 年 10 月 17 日に公開された AWS Blog “ Securing Amazon Bedrock API keys: Best practices for implementation and management ” を翻訳したものです。 2026 年 7 月 1 日 : この記事を更新し、Mantle エンドポイントで Amazon Bedrock を使用するためのガイダンスを追加しました。 AWS では、 Amazon Bedrock API を呼び出すための Amazon Bedrock API キー が利用可能です。この記事では、Amazon Bedrock へのこのアクセス方法を効果的に実装、監視、管理するための実践的なセキュリティガイダンスを紹介し、API キーを保護する包括的な戦略の構築を支援します。また、 サービス固有の認証情報 全般についても解説します。これにより、必要に応じて AWS CodeCommit や Amazon Keyspaces (Apache Cassandra 向け) の実装も強化できます。 注 : 以降、この記事では サービス固有の認証情報 と API キー を同じ意味で使用します。 Amazon Bedrock へのアクセスに最適な仕組みの選択 AWS では、可能な限り AWS Security Token Service (AWS STS) が提供する一時的なセキュリティ認証情報を認証方法として優先的に使用することをお勧めします。 ユースケースの都合で一時的な AWS STS 認証情報を使用できない場合は、API キーを使用できます。代表的な例として、HTTP ベアラートークンによる API キー認証を必須とし、 一時的な AWS STS 認証情報による SigV4 署名 を使用するよう設定できないサードパーティ製ソフトウェアやパッケージソフトウェアを使用する場合が挙げられます。 API キーを使用する必要がないと判断した場合は、 サービスコントロールポリシー (SCP) を使用して、API キーの作成と使用を拒否することを検討してください。 ユースケース上 API キーが必要だと判断した場合は、次の 2 種類の API キーのどちらを使用するか検討してください。 短期 API キー : AWS STS 認証情報を使用できない場合は、短期 API キーの使用を検討してください。短期 API キーには有効期限の仕組みが組み込まれており、指定した期間が経過すると自動的に失効します。そのため、漏洩した場合でも認証情報が無期限に使用されることを防げます。 長期 API キー : 長期 API キーは、AWS STS 認証情報も短期の認証情報も使用できない場合にのみ使用してください。例えば、長期間有効な静的 API キーを前提としており、変更できないパッケージソフトウェアや SDK を使用する場合などです。 この記事で紹介するコントロールを実装すれば、API キーに関するセキュリティ上の懸念のほとんどに対処できます。ただし、セキュリティは継続的なプロセスであることを忘れないでください。包括的なセキュリティ戦略の一環として、引き続き AWS のセキュリティに関するベストプラクティスに従い、セキュリティポスチャを定期的に見直してください。 サービス固有の認証情報について サービス固有の認証情報は、特定の AWS サービスへの直接アクセスを提供する専用の認証情報です。他の AWS セキュリティ認証情報 (アクセスキー、シークレットアクセスキー、セッショントークンなど) とは異なり、特定の AWS サービスで使用するように設計されています。 サービス固有の認証情報の主な特徴は次のとおりです。 各認証情報は特定の AWS サービスに関連付けられています AWS Identity and Access Management (IAM) プリンシパルに関連付けられています AWS マネジメントコンソールと AWS コマンドラインインターフェイス (AWS CLI) の両方で管理できます AWS CloudTrail で監視できます サービス固有の認証情報 ID の プレフィックス は ACCA です 組織は SCP を使用して、サービス固有の認証情報の作成と使用を制御できます それでは、サービス固有の認証情報と、それを Amazon Bedrock で使用する方法について詳しく見ていきましょう。 Amazon Bedrock API キー Amazon Bedrock API キー は、Amazon Bedrock への直接アクセスを提供するサービス固有の認証情報です。 アクセス許可 bedrock:CallWithBearerToken を付与すると、これらのトークンを使用して Amazon Bedrock API アクションを実行できるようになります。同様に、 アクセス許可 bedrock-mantle:CallWithBearerToken を付与すると、これらのトークンを使用して Amazon Bedrock Powered by AWS Mantle API アクションを実行できるようになります。 キーの種類と特徴 API キーには 2 種類あり、それぞれ次の特徴があります。 短期 API キー 事前署名された SigV4 認証を使用します クライアント側で生成されるため、短期 API キーの作成は CloudTrail に記録されません 認証情報レポートや AWS CLI の呼び出しでは取得できません 有効期間は、API キーを生成した IAM セッションの有効期間と 12 時間のうち、短い方です キーの生成に使用したロールと同じアクセス許可を持ちます パターン: bedrock-api-key-YmVkcm9jay5hbWF6b25hd3MuY29tLz9BY3Rpb249Q2FsbFdpdGhCZWFyZXJUb2tlbiZYLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsP[A-Za-Z0-9\\]+={0,2} 長期 API キー Amazon Bedrock コンソールから Amazon Bedrock の長期 API キーを作成すると、AWS は BedrockAPIKey-xxx という命名規則の専用 IAM ユーザーを自動的に作成し、マネージドポリシー AmazonBedrockLimitedAccess をアタッチします Amazon Bedrock コンソールから作成された IAM ユーザーでは、コンソールアクセス、コンソールパスワード、アクセスキー、多要素認証 (MFA) のいずれも有効化または設定されていません 一方、IAM コンソールから Amazon Bedrock の長期 API キーを作成する場合は、Amazon Bedrock のサービス固有の認証情報を既存の IAM ユーザーに直接関連付けることができます 各 IAM ユーザーは最大 2 つの長期 API キーを持つことができます 有効期間は 1 日から無期限までの範囲で設定できます 有効期間は、 Amazon Bedrock の API キーを管理するための新しい条件キー の 1 つである iam:ServiceSpecificCredentialAgeDays を使用して制御できます。 SCP の例 を参照してください。 パターン: ABSKQmVkcm9ja0FQSUtleS[A-Za-z0-9+\/]+={0,2} 長期 API キーが作成されると、次の例のように CloudTrail にイベントが記録されます。AWS CLI を使用して長期 API キーを特定することもできます。 { "eventTime": "2025-07-23T17:39:08Z", "eventSource": "iam.amazonaws.com", "eventName": "CreateServiceSpecificCredential", "awsRegion": "us-east-1", "sourceIPAddress": "203.0.113.1", "userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:139.0) Gecko/20100101 Firefox/139.0", "requestParameters": { "userName": "BedrockAPIKey-0g21", "serviceName": "bedrock.amazonaws.com", "credentialAgeDays": 36500 }, "responseElements": { "serviceSpecificCredential": { "createDate": "Jul 23, 2025, 5:39:08 PM", "expirationDate": "Oct 7, 2125, 5:39:08 PM", "serviceName": "bedrock.amazonaws.com", "serviceCredentialAlias": "BedrockAPIKey-1234-56-EXAMPLE", "serviceCredentialId": "ACCA123456789EXAMPLE", "userName": "BedrockAPIKey-0g21", "status": "Active" } } } 識別 API キーを扱う際に理解しておくべき重要な点がいくつかあります。短期 API キーはクライアント側で生成されるため、 ListServiceSpecificCredentials などの AWS API で既存の認証情報を一覧表示しても、短期 API キーは含まれません。 長期 API キーは短期 API キーより可視性が高く、複数の方法で管理できます。長期 API キーが関連付けられているプリンシパルは、 Amazon Bedrock コンソール または IAM コンソール で特定できます。また、 AWS CLI コマンドまたは AWS SDK を使用すると、指定したユーザーのサービス固有の認証情報を一覧表示できます。 防御 Amazon Bedrock では、AWS 環境における API キーの使用をより適切に制御、保護するための 4 つの条件キー が導入されました。 条件キー iam:ServiceSpecificCredentialServiceName を使用すると、プリンシパルによるサービス固有の認証情報の作成を許可する AWS サービスを指定できます。 条件キー iam:ServiceSpecificCredentialAgeDays を使用すると、長期 API キーの作成時に最大有効期間を設定して、セキュリティのベストプラクティスを適用できます。 条件キー bedrock:BearerTokenType を使用すると、Amazon Bedrock で、特定の種類 (短期または長期) の API キーの使用を拒否または許可できます。 条件キー bedrock-mantle:BearerTokenType を使用すると、同様に Amazon Bedrock Powered by AWS Mantle で、特定の種類 (短期または長期) の API キーの使用を拒否または許可できます。 これらの条件キーは、短期 API キーと長期 API キーそれぞれのセキュリティ特性の違いを管理するうえで重要な役割を果たします。セキュリティチームはこれらを利用して、AWS Organizations レベルの SCP で組織のポリシーとセキュリティのベストプラクティスを適用できます。詳細については、これらの SCP の適用例を紹介している GitHub リポジトリ を参照してください。 短期 API キーには有効期限が組み込まれているため、潜在的なセキュリティリスクにさらされる期間を抑えられます。ただし、これらのキーは署名に使用したプリンシパルのアクセス許可を継承するため、Amazon Bedrock 以外のアクセス許可も含まれる場合がある点に注意してください。包括的な監視は、 「検知」 セクションで説明する方法で実装できます。 長期 API キーは有効期間を長く設定できるため、長時間実行されるアプリケーションには便利です。ただし、認証情報が悪用されうる期間が長くなる分、それを補うためのコントロールと監視の仕組みに特に注意を払う必要があります。 組織の環境で Amazon Bedrock API キーが不要と判断した場合は、SCP を実装して、サービス固有の認証情報の作成 ( iam:CreateServiceSpecificCredential ) と、Amazon Bedrock でのベアラートークンの使用 ( bedrock:CallWithBearerToken および bedrock-mantle:CallWithBearerToken ) をブロックできます。 注: IAM ポリシーで条件 iam:ServiceSpecificCredentialServiceName を使用せずに iam:CreateServiceSpecificCredential を拒否すると、 AWS CodeCommit や Amazon Keyspaces (Apache Cassandra 向け) など、他のサービスの API キーの作成も拒否されます。 こちらの SCP の例 では、Amazon Bedrock のサービス固有の認証情報の作成と、Amazon Bedrock での API キーの使用を拒否しています。これにより、組織内のビルダーが新しい API キーを作成できなくなり、不正なキー作成のリスクを軽減できます。このアプローチは、認証方法を厳格に管理したい組織や、サービス固有の認証情報を必要とするビジネス上の理由がない組織に有効です。また、 aws:PrincipalArn に指定したプリンシパルを対象とする条件 ArnNotLikeIfExists を SCP に追加すれば、特定のロールを許可リストに登録して、サービス固有の認証情報を作成できるようにすることもできます。 API キー保護の一環として、最小権限の原則に沿ってアクセス許可を定期的に見直し、調整してください。Amazon Bedrock コンソールから長期 API キーを作成すると、AWS はマネージドポリシー AmazonBedrockLimitedAccess がアタッチされた IAM ユーザーを自動的に作成します。このポリシーは、Amazon Bedrock、 AWS Key Management Service (AWS KMS) 、IAM、 Amazon Elastic Compute Cloud (Amazon EC2) 、AWS Marketplace のさまざまなアクションへのアクセスを許可します。長期 API キーと短期 API キーのどちらについても、プリンシパルがユースケースに必要な範囲を超えるアクセス許可を持っていないか評価してください。過剰なアクセス許可が見つかった場合は、ポリシー AmazonBedrockLimitedAccess を、アクセス許可の範囲を絞り込んだカスタムポリシーに 置き換え てください。 検知 API キーには、種類に応じて異なる監視アプローチが必要です。短期 API キーはクライアント側で生成されるため作成を検知できませんが、長期 API キーの作成は CloudTrail イベントで監視できます。 Converse 、 ConverseStream 、 InvokeModel 、 InvokeModelWithResponseStream への推論呼び出しは、管理イベントとして CloudTrail に記録されます。CloudTrail に記録されるこれらのイベントを通じて、短期 API キーと長期 API キーのどちらについても、その 使用 を検知できます。長期 API キーは有効期間が長いため不正使用されやすく、包括的な監視が不可欠です。組織は、次のような厳格な監視コントロールを実装する必要があります。 CreateUser イベントのうち、ユーザー名に BedrockAPIKey- プレフィックスが付いているものを監視します。Amazon Bedrock コンソールからユーザーが作成された場合、イベントは次のようになります。 { "eventTime": "2025-07-23T17:39:08Z", "eventSource": "iam.amazonaws.com", "eventName": "CreateUser", "awsRegion": "us-east-1", "sourceIPAddress": "203.0.113.1", "userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:139.0) Gecko/20100101 Firefox/139.0", "requestParameters": { "userName": "BedrockAPIKey-0g21" }, "responseElements": { "user": { "path": "/", "userName": "BedrockAPIKey-0g21", "userId": " AIDACKCEVSQ6C2EXAMPLE", "arn": "arn:aws:iam::111122223333:user/BedrockAPIKey-0g21", "createDate": "Jul 23, 2025, 5:39:08 PM" } } } CreateServiceSpecificCredential イベントのうち、 requestParameters.serviceName = bedrock.amazonaws.com を満たすものを追跡します API キーがアクティブに使用されていることを示す次の指標を監視します additionalEventData.callWithBearerToken = true eventSource = bedrock.amazonaws.com { "eventVersion": "1.11", "userIdentity": { "type": "IAMUser", "principalId": " AIDACKCEVSQ6C2EXAMPLE", "arn": "arn:aws:iam::user/BedrockAPIKey-0g21", "accountId": "", "userName": "BedrockAPIKey-0g21" }, "eventTime": "2025-07-23T17:39:37Z", "eventSource": "bedrock.amazonaws.com", "eventName": "Converse", "awsRegion": "us-east-1", "sourceIPAddress": "", "userAgent": "curl/8.11.1", "requestParameters": { "modelId": "us.anthropic.claude-3-5-haiku-20241022-v1:0" }, "responseElements": null, "additionalEventData": { "callWithBearerToken": true, "inferenceRegion": "us-west-2" } } 監視すべきイベントの一覧については、「 Security Playbook for Responding to Amazon Bedrock Security Events 」を参照してください。 Amazon EventBridge ルール Amazon EventBridge ルールを実装すると、CreateServiceSpecificCredential などの Amazon Bedrock API キーのライフサイクルイベントを検知してアラートを送信できるため、セキュリティ監視を強化できます。 EventBridge ルールを使用した監視は、次の 4 つのコンポーネントで構成されます。 EventBridge ルール : CreateServiceSpecificCredentialRule と BearerTokenUsageRule が、認証情報の作成とベアラートークンの使用を CloudTrail で監視します SNS トピック : BedrockAlertsTopic が、暗号化されたセキュリティアラートを E メールで配信します KMS キー : SNSEncryptionKey が SNS メッセージを暗号化します IAM ロール: サービスの運用に必要なアクセスを提供します 前述の EventBridge ルールは、 eventName (実行されているアクション)、 eventSource (アクションの実行主体または対象となるサービス)、 additionalEventData (レスポンスの詳細を含むブロック) をキーとして、CloudTrail ログ内の特定のパターンを監視します。 次のルールは、CloudTrail イベント CreateServiceSpecificCredential をチェックします。 source: - aws.iam detail-type: - AWS API Call via CloudTrail detail: eventSource: - iam.amazonaws.com eventName: - CreateServiceSpecificCredential API キーを使用して実行されたアクション ( BearerToken = true ) を検索するには、次のルールを使用します。 detail-type: - AWS API Call via CloudTrail detail: additionalEventData: callWithBearerToken: - true EventBridge ルールのデプロイ CloudFormation テンプレート を使用すると、サービス固有の認証情報の作成とその後の使用の両方を自動で監視するよう設定できます。このテンプレートは、前述の CloudTrail イベントが検知されたときに E メール通知を送信するよう EventBridge を設定するため、環境内の API キー操作をリアルタイムで把握できます。詳細については、GitHub リポジトリにあるこのソリューションの 説明 と CloudFormation テンプレート を参照してください。 コンプライアンスのための AWS Config ルール AWS Config ルールを使用して、IAM ユーザーがアクティブなサービス固有の認証情報を持っていないかを監視することで、セキュリティポリシーへの準拠を維持しやすくなります。 AWS Config ルール は、次の手順を実行します。 AWS Config ルールが 24 時間ごとに Lambda 関数をトリガーし、この関数がアカウント内の IAM ユーザーを列挙します 関数は、ユーザーごとにアクティブなサービス固有の認証情報の有無を確認します サービス固有の認証情報を持つユーザーは NON_COMPLIANT としてマークされます アクティブな認証情報を持たないユーザーは COMPLIANT としてマークされます 結果は、レポートと必要に応じた修復のために AWS Config に送信されます AWS Config ルールのデプロイ この AWS Config ルールは、 AWS Config RDK を使用して、CloudShell またはローカルの CLI からデプロイできます。 git clone https://github.com/awslabs/aws-config-rules.git cd aws-config-rules/python-rdklib git fetch && git checkout IAM_USER_NO_SERVICE_SPECIFIC_CREDENTIALS pip install rdk rdklib rdk deploy IAM_USER_NO_SERVICE_SPECIFIC_CREDENTIALS aws configservice start-config-rules-evaluation --config-rule-names "IAM_USER_NO_SERVICE_SPECIFIC_CREDENTIALS" 対応と復旧 インシデント対応計画は、いずれも準備フェーズから始まります。準備フェーズの一環として、API キーの所有者と使用状況を明確に記録し、どのアプリケーションやチームがどのキーを使用しているかを文書化してください。また、長期 API キーが必要な場合は、 AWS Secrets Manager などの安全なストレージの使用を検討してください。 API キーに関連するセキュリティインシデントが疑われる場合は、直ちに行動することが重要です。最初のステップは、CloudTrail ログを確認して API キーの作成と使用を承認済みの変更リクエストと照合し、侵害の可能性を検証することです。これにより、不正なキーの作成や使用を特定できます。さらに、これらのログに記録された送信元 IP アドレスとユーザーエージェント文字列を分析すれば、アクセス元が承認済みの場所やアプリケーションなのか、悪意のある可能性がある送信元なのかを判断できます。 インシデント対応のアプローチは、キーの種類によって大きく異なります。短期 API キーの場合、有効期限が最大 12 時間であるため潜在的な被害は限定されますが、有効期限切れを待たずに直ちに対処することが重要です。セキュリティチームは、侵害された短期 API キーを使用しているアプリケーションやシステムを特定し、IAM ロールセッションを 取り消す か、アイデンティティに対して bedrock:CallWithBearerToken および bedrock-mantle:CallWithBearerToken のアクセス許可を拒否する必要があります。 進行中のセキュリティイベントに Amazon Bedrock の長期 API キーが関与している場合、セキュリティチームはコンソールまたは AWS CLI を使用して直ちに対処できます。コンソールでは、IAM コンソールを使用して長期 API キーをすばやく 無効化 または 削除 できます。対応手順を自動化している組織向けには、AWS CLI にキー管理用のコマンドが用意されています。 AWS CLI を使用した対応 API キーに関するイベントに対応するには、次の手順を実行します。 サービス固有の認証情報を特定します。 aws iam list-service-specific-credentials --user-name <user name> --service-name bedrock.amazonaws.com 直ちに封じ込めるには、前の手順で取得した認証情報 ID を使用して認証情報を 無効化 します。 aws iam update-service-specific-credential --service-specific-credential-id <credential ID> --user-name <user name> --status Inactive イベントを評価した後、関連付けられた API キーを 完全に削除 できます。 aws iam delete-service-specific-credential --service-specific-credential-id <credential ID> --user-name <user name> 復旧フェーズでは、適切な設定で安全な新しいキーを作成し、アプリケーションの設定を更新するとともに、影響を受けるすべての継続的インテグレーションおよび継続的デリバリー (CI/CD) パイプラインと開発チームに変更を確実に通知することに重点を置いてください。 Amazon Bedrock API キーに関する対策の概要 次の表は、Amazon Bedrock API キーに関連するさまざまな要素を、 NIST CSF 2.0 のコア機能 に対応付けてまとめたものです。 種類 識別 防御 検知 (CloudTrail のイベントを使用) 対応 短期 API キー 短期 API キーはクライアント側で生成されるため、AWS API では一覧表示されません。 作成 : 短期 API キーはクライアント側で生成されるため、作成をブロックすることはできません。 使用 : 使用を防ぐには、アクション bedrock:CallWithBearerToken と bedrock-mantle:CallWithBearerToken を拒否します。 長期および短期の Amazon Bedrock API キーのアクセス許可を変更する 作成 : クライアント側で行われるため、CloudTrail にイベントは記録されません。 使用 : additionalEventData.callWithBearerToken = true を含む CloudTrail イベント API キーの使用を検知して通知するための EventBridge ルールと SNS 。 IAM ロールセッションの 取り消し 、またはアイデンティティに対するアクセス許可の拒否 長期 API キー AWS CLI または SDK を使用した IAM のアクション ListServiceSpecificCredentials 作成 : アクション iam:CreateServiceSpecificCredential を拒否すると、Amazon Bedrock を含むすべてのサービスでサービス固有の認証情報の作成をブロックできます。 使用 : 使用を防ぐには、アクション bedrock:CallWithBearerToken と bedrock-mantle:CallWithBearerToken を拒否します。 長期および短期の Amazon Bedrock API キーのアクセス許可を変更する 作成 : eventName が CreateServiceSpecificCredential の CloudTrail イベント。Amazon Bedrock コンソールを使用した場合は、 CreateUser イベントも対象です。 使用 : additionalEventData.callWithBearerToken = true を含む CloudTrail イベント API キーの作成と使用を検知して通知するための EventBridge ルールと SNS 。 AWS Config ルール コンソールまたは AWS CLI を使用して、長期 API キーをすばやく 無効化 または 削除 します Amazon Bedrock 以外のサービス固有の認証情報 Amazon Bedrock の API キーのほかにも、AWS CodeCommit や Amazon Keyspaces などの AWS サービスが サービス固有の認証情報をサポート しています。 この記事で紹介したセキュリティ対策は、これらのサービスにも適用できます。次の表は、これらのサービス固有の認証情報の一般的なユースケースを示しています。 サービス ユースケース iam:ListServiceSpecificCredentials のレスポンスに含まれるサービス名 推奨される代替手段 AWS CodeCommit の Git 認証情報 AWS CodeCommit リポジトリ内のファイルのアップロード、追加、編集に使用 codecommit.amazonaws.com SSH 認証やフェデレーション認証などの方法があります。詳細については、「 AWS CodeCommit: 他の方法を使用したセットアップ 」を参照してください Apache Cassandra 向けの Amazon Keyspaces 認証情報 Apache Cassandra 互換のアクセスに使用 cassandra.amazonaws.com SigV4 認証プラグインを利用できます。このプラグインは複数のプログラミング言語をサポートしており、IAM ロールやフェデレーティッドアイデンティティによる認証を可能にします。詳細については、「 IAM ロールと SigV4 プラグインを使用して Amazon Keyspaces に接続するための一時的な認証情報を作成する 」を参照してください まとめ 長期 API キーがもたらす影響とその管理方法を理解しておくと、Amazon Bedrock API キーの実装戦略について、十分な情報に基づいた判断を下せます。重要なのは、強固なセキュリティポスチャを維持しながら、セキュリティコントロールをリスク選好度と運用要件に合わせることです。 AWS は、可能な限り AWS STS 認証情報を主要な認証方法として使用することを強く推奨しています。AWS STS 認証情報を使用できない場合は、有効期限の仕組みが組み込まれた短期 API キーを検討してください。長期 API キーは、AWS STS 認証情報も短期の認証情報も選択肢にならない場合にのみ実装してください。API キーを実装する際に組織として重点を置くべき点は、次のとおりです。AWS CLI と CloudTrail ログを使用して API キーを識別すること、SCP などの予防的コントロールで API キーの作成と使用を管理して防御すること、CloudTrail イベント、EventBridge、AWS Config ルールによる包括的な監視で API キーのアクティビティを検知すること、そして明確なインシデント対応手順を整備し、侵害された可能性のある API キーに迅速に対応することです。 ベストプラクティスは、最小権限の原則に基づく適切なアクセスコントロールを維持しながら、これらのコントロールを実装することです。この多層的なアプローチにより、開発ニーズに合わせて API キーを効果的に活用しつつ、強固なセキュリティポスチャを維持できます。 この記事に関するご質問は、 AWS サポートにお問い合わせ ください。 Jennifer Paz Jennifer は 10 年以上の経験を持つ Security Engineer で、現在は AWS Customer Incident Response Team (CIRT) に所属しています。お客様のセキュリティ課題の解決を支援し、セキュリティポスチャを強化するための複雑なソリューションを実装することにやりがいを感じています。仕事以外では、熱心なランナーであり、ピックルボール愛好家、旅行好き、グルメでもあり、常に新しい食の冒険を探し求めています。 Kyle Dickinson かつて Gibson を探索していた私は、今ではクラウドセキュリティの専門家です。AWS の Sr. Security Solution Architect として、かつて探索していたシステムを今は守っています。AWS のお客様を守っていないときは、LEGO 作品を組み立てたり、大けがをせずにロングボードの腕を上げようと奮闘したりしています。家庭生活は、自信たっぷりの小さな犬と、いつも笑わせてくれる元気な 4 歳の娘を中心に回っています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

2026 年 10 月 12 日、コードをイベントハンドラーに書き直さずに標準の HTTP ウェブアプリケーションを Lambda で実行できる新しいフォームファクターである AWS Lambda Web Functions を発表しました。Express、Hono、Fastify、Next.js、または任意の Node.js フレームワークで構築された標準のポートリスニングサーバーを 1 つのコマンドでデプロイできます。Lambda は、スケーリング、マルチリージョン分布、アクティブな CPU 請求を自動的に処理します。アダプター、管理するインフラストラクチャ、フレームワークのロックインはありません。 今回の発表により、AWS Lambda は 3 つの異なるフォームファクターを提供するようになりました。各フォームファクターは同じ Firecracker 分離テクノロジーに基づいて構築され、異なるプログラミングモデル向けに設計されています。 Lambda Event Functions は、すでに Lambda 関数として知られているものです。イベント駆動型の単一同時ハンドラーモデルとウォールクロック課金方式を採用しています。「イベント関数」という名前は、そのプログラミングモデル、つまり関数がイベントを受け取って処理し、応答を返すということを強調するためです。イベント駆動型プログラミングモデルは、イベント処理、キューコンシューマー、および他の AWS サービスによってトリガーされる呼び出しに最適です。 Lambda Web Functions は、マルチコンカレント実行とアクティブ CPU 課金が可能な HTTP ネイティブプログラミングモデルを使用しています。コードはポートでリッスンし、標準の HTTP リクエストを処理します。このプログラミングモデルは、複数の同時リクエストと I/O の多い処理が標準となっているウェブアプリケーション、API バックエンド、インタラクティブな HTTP ワークロードに最適です。 Lambda MicroVMは 、信頼できないコードやユーザーが生成したコードを実行するための顧客管理のライフサイクルを備えた、分離されたステートフルなサンドボックス環境を提供します。 この3つは互いに補完し合っています。アプリケーションでは、非同期バックエンド処理にはイベント関数、ユーザー向け API とサーバー側レンダリングレイヤーには Web Functions、インタラクティブなコード実行機能には MicroVM を使用する場合があります。これらはすべて同じ AWS アカウント内で同じ運用モデルを共有します。 なぜウェブファンクションなのか 最新のウェブアプリケーションでは、開発者が標準フレームワークを自由に使用して迅速に反復できるようにしながら、高速で一貫した応答時間で世界中のユーザーにサービスを提供する必要があります。今日これを構築するには、通常、複数のインフラストラクチャコンポーネントを組み立て、マルチリージョン展開を構成し、レイテンシーベースのルーティングを設定し、I/O待機による支払いを回避するための請求モデルのチューニングが必要です。開発者は、すでに所有しているHTTPサーバーをデプロイするのではなく、特定のコンピューティングモデルに合わせてアプリケーションコードを調整していることに気付くことがよくあります。 Lambda ウェブ関数はこの複雑さを解消します。各実行環境は複数のリクエストを同時に処理します（環境ごとに最大128の同時リクエスト）。つまり、各リクエストを新しいリクエストにマッピングする代わりに、大量の受信トラフィックがウォーム環境を共有できます。Web Functions はコードが使用する CPU 時間を計測するため、データベースクエリや API 呼び出しの待機時間が CPU をほとんど消費しません。メモリは、実行環境が存在する限り計測されます。サーバーサイドレンダリング、API バックエンド、トークン応答をストリーミングする AI 推論エンドポイントなど、I/O の多いウェブワークロードでは、これによりコンピューティングコストを削減できます。 試してみましょう はじめに、単純な Express.js サーバーを作成しました。これは node index.js を使用してローカルで実行するのと同じコードで 、Lambda 固有のアダプターやラッパーは必要ありません。 「エクスプレス」からエクスプレスをインポート; const アプリ = エクスプレス (); const [ホスト, ポート] = process.env.aws_lambda_http_Endpoint.split (':'); app.get ('/', (req, res) => { res.json ({メッセージ:'ラムダウェブ関数からこんにちは!'}); }); app.listen (ポート、ホスト、() => { console.log(`Server running on port ${port}`); }); ローカルでの実行との唯一の違いは、 AWS_LAMBDA_HTTP_ENDPOINT 環境変数です。Lambda はこの変数を、サーバーがリッスンする必要があるホストとポートに設定します。ローカルで実行するには、自分で設定します。たとえば、 AWS_LAMBDA_HTTP_ENDPOINT=127.0.0.1:3000 node index.js のように設定します。 コードの準備ができたら、 AWS コマンドラインインターフェイス (AWS CLI) を使用してデプロイしました。 aws lambda-web deploy --name my-web-app --code ./my-app 1 つのコマンド。事前のリソース設定はありません。CLIはソースをバンドルし、Webファンクションを作成し、最初のリビジョンを公開し、Webファンクションエンドポイントをアタッチして、1分以内にライブHTTPSURLを返しました。 リビジョンは、デプロイしたコードの不変のスナップショットです。エンドポイントは、トラフィックをリビジョンにルーティングしたり、トラフィックをリビジョン間で分割したりする HTTPS URL です。これらは、反復作業を行い、新しいコードへトラフィックをどのように移行させるかを制御するために使用するリソースです。 私はすぐにそれをテストしました： <shard-id>$ curl https://<domain-id>. .lambda-web.us-east-1.on.aws/ {「メッセージ」:「Lambda Web Functionsからこんにちは!」} 次に、自分のアプリケーションがヨーロッパとアジアのユーザーに低レイテンシーでサービスを提供できるようにしたかったのです。複数のリージョンで再デプロイしました。 aws lambda-web deploy --name my-web-app --code ./my-app \ --regions us-east-1,eu-west-1,ap-northeast-1 Lambda Web Functions は私のコードを 3 つのリージョンすべてに複製し、レイテンシーベースのルーティングを自動的に設定しました。これで、各リクエストは、ベストエフォート方式で 1 つのグローバル URL ( <domain-id>.lambda-web.global.on.aws ) を介して、呼び出し側のレイテンシーが最も低いリージョンにルーティングされるようになりました。。 コードを更新して同じデプロイコマンドを再度実行すると、CLIは既存の関数を検出し、新しいリビジョンをアップロードして、エンドポイントにそのリビジョンを指定しました。コード変更から本番稼働までの合計所要時間: 秒。 より段階的なロールアウトが必要なプロダクションワークフローでは、1 回の API 呼び出しでリビジョン間でトラフィックをシフトできます。 aws lambda-web update-web-function-endpoint \ --function-name my-web-app \ --endpoint-name dev \ --auto-deployment-mode Disabled \ --revision-weights 『[{「revisionId」: 「<current-revision-id>」, 「weight」: 90}, {「revisionId」: 「<new-revision-id>」, 「weight」: 10}]』 これにより、エンドポイントトラフィックの90％が現在のリビジョンに、10％が新しいリビジョンに送られるため、追加のツールなしでカナリアデプロイメントを行うことができます。 Amazon CloudFront と併用するとさらに便利に 静的コンテンツと動的コンテンツを組み合わせるアプリケーションの場合、ウェブ関数は Amazon CloudFront と併用するとうまく機能します。ウェブ関数エンドポイントを CloudFront ディストリビューションのオリジンとして選択できます。静的アセットはキャッシュから提供され、動的リクエストはWeb Functionにルーティングされるため、動的部分のサーバーレスコンピューティングで静的コンテンツのCDNパフォーマンスを実現できます。 ウェブ機能により、CloudFront のプライベートオリジンエクスペリエンスが向上します。 今回の起動では、代わりに CloudFront オリジンアクセスコントロール (OAC) をウェブ関数エンドポイントにアタッチします。CloudFront はオリジンへのリクエストに署名し、エンドポイントはディストリビューションのみがそれを呼び出すことを許可します。エンドポイントを公開したり、アプリケーションにカスタム認証を追加したりしなくても、CloudFront がすでに Amazon Simple Storage Service (Amazon S3) に提供しているのと同じプライベートオリジンパターンが得られます。 今すぐご利用いただけます AWS Lambda Web Functions は現在、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、アジアパシフィック (東京)、および欧州 (アイルランド) でご利用いただけます。ウェブ関数は起動時に Arm64 で Node.js 24 (nodejs24.x) を実行し、Amazon 仮想プライベートクラウド (VPC) 接続をサポートします。これにより、関数が VPC 内に存在するリソースにアクセスできるようになります。 始めるには、最初の Web 関数を 1 分以内にデプロイしてください。 aws lambda-web deploy --name hello-world --hello-world 料金の詳細については、 AWS Lambda の料金表ページをご覧ください 。詳細については、 Lambda ウェブ関数のドキュメントを参照してください 。 原文は こちら です。