AWSの薄い本 全巻セット
Physical (worldwide shipping)
- 全6巻セット・物理本＋ダウンロード版Ships within 10 daysShips by Anshin-BOOTH-PackPhysical (direct)5,900 JPY
Physical (ship to Japan)/ Digital Download
- 全6巻セット・物理本＋ダウンロード版Ships within 10 daysShips by Anshin-BOOTH-PackPhysical (direct)5,900 JPY
- 全6巻セット・ダウンロード版Digital5,900 JPY
全巻セット限定！技術同人誌『AWSの薄い本』6冊パック 『IAMのマニアックな話』をはじめとするシリーズ累計１万4千冊以上の大人気シリーズを、全部まとめて21%オフで買えます！！
セット内容と商品情報
クラウド技術やAWSに関する知識を深めるための、究極のセットが登場！これまでに発行した6冊の技術同人誌を、特別価格でまとめてご提供します。 IAMのマニアックな話 アカウントセキュリティのベーシックセオリー データ分析基盤を作ってみよう 〜設計編〜 昔話で振り返るAWSの歩み データ分析基盤を作ってみよう 〜性能測定編〜 IAMのマニアックな話 2025
目次 アカウントセキュリティのベーシックセオリー
はじめに 本書の目的 対象読者 本書で得られること 本書で得られないこと お問い合わせ先 免責事項 第1章 AWSアカウントセキュリティ 1.1 AWSのセキュリティとサービスの概念図 AWS上に構築するシステムのセキュリティ AWSアカウント自体の管理（IAMの設計・運用） セキュリティを維持管理するための施策 1.2 責任共有モデル 1.3 AWS上に構築するシステムのセキュリティ 1.4 AWSアカウントの管理 1.5 セキュリティを維持管理するための施策 1.6 マルチアカウント管理 第2章 ガードレールという設計と思想 2.1 Control Towerの全体像 2.2 ガードレールの設計と思想 2.3 予防と検知の実体 第3章 AWSのセキュリティサービス 3.1 NISTサイバーセキュリティフレームワーク CSF コア 3.2 AWSのセキュリティサービスの全体像と対象領域 3.3 CloudTrail CloudTrailの注意点 CloudTrailのログ集約 3.4 Config Config Config Rules 3.5 GuardDuty GuardDutyの分析対象 脅威の重要度と通知・対処 3.6 Security Hub Security Hubの集約対象 3.7 AWS Organizations AWS Organizationsの構成要素 組織単位（OU）と階層構造 サービスコントロールポリシー（SCP） SCPとIAMのアクセス許可の境界 3.8 Trusted Advisor 第4章 サンドボックスアカウントの作成のチュートリアル 4.1 サンドボックス環境の要件 4.2 サンドボックス環境の全体像 4.3 設定の流れ 4.4 Organizationsの設定 Organizationの作成 サンドボックスアカウントの作成 組織単位（OU）の作成 OU配下にアカウントを移動 4.5 マスターアカウントでの設定 設定用のIAMユーザー作成 IAMのアクセスアナライザーの設定 組織に対するCloudTrailの設定 Configの有効化 Configのアグリゲータの設定 Security Hubの有効化 4.6 サンドボックスアカウントの設定 Organizationsで作成したAWSアカウントへのログイン 設定用のIAMユーザー作成 監視・監査ログの収集と集約 4.7 問題の検知と通知 セキュリティグループの全開放を検知するConfig Rule 4.8 問題検知時の復旧 SSMで利用するIAMロールの作成 自動修復の設定 修復の確認 4.9 アカウントのサンドボックス化 サービスコントロールポリシー（SCP）の有効化と設定 禁止行為を抑制するポリシーを作成する サンドボックスアカウントにポリシーを適用する 第5章 CloudFormationを利用した構成管理 5.1 CloudFormationで管理する理由 5.2 CloudFormationで管理する範囲 5.3 複数アカウントに適用するCFn StackSets CFn StackSetsとOrganizationsの連携 5.4 StackSetsのチュートリアル StackSetsの作成 テンプレートの選択 StackSetsの権限設定 デプロイターゲットの設定 動作確認 5.5 テンプレートの設計 サービスのセットアップとルール設定の分離 アカウント共通設定と個別設定の境界 CloudFormationの具体的な構造 5.6 CloudFormationのまとめ 第6章 アカウントセキュリティの設計の考え方の原則 6.1 CSFコアとAWSの設計原則にみるセキュリティ 6.2 AWSのセキュリティ ベストプラクティス アイデンティティ管理とアクセス管理 発見的統制 インフラストラクチャ保護 データ保護 インシデント対応 6.3 セキュリティ設計のまとめ 第7章 障害の検知と復旧の考え方 7.1 AWSの運用の原則を知る 7.2 AWSのサービスを使った検知と復旧 7.3 統合サービス Security Hubの位置づけ 7.4 Security Hubと個別検知の使い分け 7.5 監視と検知 7.6 通知 7.7 対応と復旧 AWSの自動復旧のパターン 7.8 Security Hubの活用 第8章 まとめとマルチアカウント管理への道 8.1 セキュリティ設計と運用 8.2 Organizationsのサービスコントロールポリシー 8.3 Security Hubの導入 8.4 マルチアカウント管理への道 8.5 まとめ あとがき 著者紹介 既刊一覧
目次 IAMのマニアックな話
はじめに 本書の目的 対象読者 本書で得られること お問い合わせ先 免責事項 第1章 AWS と IAM 1.1 認証と認可 1.2 AWS のアカウント種類 1.3 AWSアカウント 1.4 IAM ユーザ 1.5 注意とお願い 第2章 IAM の機能 2.1 IAM ユーザー 2.2 IAM グループ 2.3 IAM ポリシー 2.4 IAMロール 2.5 パーミッション・バウンダリー 2.6 IAMの機能のまとめ 【コラム】 AWSアカウントとIAMの関係 第3章 IAM チュートリアル 3.1 IAMポリシーの作成 3.2 IAMグループの作成 3.3 IAMユーザーの作成 3.4 クロスアカウントロールの作成 3.5 チュートリアルのまとめ 第4章 IAM ポリシーのデザインパターン 4.1 ホワイトリスト・パターン 4.2 ブラックリスト・パターン 4.3 ハイブリット・パターン 4.4 IAMポリシーのまとめ 【コラム】 最小権限の探求 第5章 IAM グループのデザインパターン 5.1 複数グループに所属 5.2 グループ内に複数ポリシー 5.3 IAMグループのまとめ 【コラム】 IAMグループの階層構造について 第6章 IAM とセキュリティ 6.1 IAMベストプラクティスの遵守 6.2 ルートユーザーを使わない 6.3 IAMに関する権限付与 6.4 Lambdaのリソースベースの権限 6.5 インターネット公開系の権限 【コラム】 ec2の権限範囲の問題 6.6 VPC内からのアクセス 6.7 アクセスキーの原則禁止 6.8 CapitalOneの情報流出事件に思うこと 6.9 IAMとセキュリティのまとめ 【コラム】 IPアドレス制限の是非とゼロトラストセキュリティ 第7章 IAM の運用 7.1 IAMの運用の目的 7.2 役割と責任範囲の明確化 7.3 AWS アカウントの管理 7.4 IAM ユーザーの管理 7.5 アクセスキーの管理とCLI 7.6 MFA 未利用時に権限を制限し、MFA 利用を促す 7.7 マルチアカウントでの運用 7.8 IAM運用のまとめ 第8章 IAMとCloudFormation 8.1 IAMとCloudFormation 8.2 CFnの分割単位・依存関係 8.3 CloudFormationとIP制限 【コラム】 ライフサイクルで考える 第9章 IAMのテンプレート集 9.1 共通系ポリシー 9.2 管理者グループ 9.3 ネットワーク管理者グループ 9.4 開発者グループ 9.5 オペレーターグループ 9.6 経理担当者グループ 9.7 お一人様AWS 9.8 IAMのテンプレートのまとめ 第10章 IAM以外のAWS サービスの活用 10.1 AWS Organizations(組織アカウント) 10.2 AWS CloudTrailとAWSConfig 10.3 Amazon GuardDuty 10.4 AWS ControlTowerとAWS SecurityHub 10.5 今後のAWS運用について 10.6 まとめ 付録 A アカウント開設時の設定チェックリスト
目次 データ分析基盤を作ってみよう 〜設計編〜
はじめに 本書の目的 対象読者 本書で得られること 本書で得られないこと お問い合わせ先 免責事項 第1章 データ分析基盤が必要とされる理由 1.1 加速するデータ活用 1.2 ビッグデータとデータ活用 1.3 データ分析とクラウド 1.4 データ分析の⺠主化 第2章 データ分析基盤の全体像と構成要素 2.1 データ分析基盤の定義と全体像 2.1.1 データレイク 2.1.2 ETL 2.1.3 DWH 2.2 データの内部構造による分類 2.2.1 構造化データ/半構造化データ/非構造化データ 2.2.2 構造化に伴う情報の切り捨て 2.3 データレイク 2.3.1 データレイクとは? 2.3.2 AWSにおけるデータレイクサービス 2.4 DWH 2.4.1 DWH とは? 2.4.2 AWSにおけるDWHサービス 2.5 ETL(Extract/Transform/Load) 2.5.1 ETLとは? 2.5.2 AWSにおけるETL 第3章 データレイクと DWH のアーキテクチャ 3.1 よくあるデータ分析基盤の課題 3.1.1 DWHだけで運用していて自由度が低い 3.1.2 必要最低限のデータのみ蓄積され、他の分析ができない 3.1.3 個人情報の取り扱い方針の問題で使いにくい 3.1.4 分析を変更するたびに、外部ベンダーに依頼する必要がある 3.2 データレイクとDWHを分離する 3.3 データレイクの3層構造 3.3.1 RAWデータレイク 3.3.2 中間データレイク 3.3.3 構造化データレイク 3.4 データレイクを3層構造にすることのメリット 3.4.1 RAW データが残っているので、観点が変わっても分析し直せる 3.4.2 中間データレイクがあると、様々な結合が容易にできる 3.4.3 構造化データレイクに対して、直接クエリーで検索できる 第4章 個人情報と加工方法と保持戦略について 4.1 個人情報とパーソナルデータの定義について 4.1.1 個人情報 4.1.2 パーソナルデータ 4.2 個人情報の加工について 4.2.1 匿名加工情報 4.2.2 匿名加工の方法 4.2.3 仮名加工情報 4.3 データ分析基盤における個人情報の扱い 4.3.1 個人情報の取り扱い戦略 4.3.2 ノーガード戦略 4.3.3 全部入り戦略 4.3.4 全部なし戦略 4.3.5 分離パターン戦略 4.4 項目加工のパターンについて 4.5 まとめ 第5章 データ加工について 5.1 ETL処理のパターン 5.1.1 ETL 5.1.2 ELT 5.1.3 データプレパレーションツール 5.2 ELTの実装 5.2.1 UPSERTとは? 5.2.2 Athena における Upsert 的な機能の実装方法 5.3 GUIによるデータ加工について 5.3.1 データプレパレーションツール 5.3.2 加工とデータの所在について 5.3.3 データ加工の場所 5.3.4 データの連携方法 5.3.5 どのパターンが良いか? 5.3.6 クラウド事業者が提供するデータプレパレーションツール 5.4 データ加工のまとめ 第6章 アクセス制御 6.1 アクセス制御の種類 6.2 権限ベースのアクセス制御 6.2.1 原則的に人に対して S3 へのアクセス権限を与えない 6.2.2 バケットレベルのアクセス制限を IAM で制御すべきか? 6.2.3 サービスやプログラムへの権限付与 6.3 リソースベースのアクセス制御 6.3.1 経路の限定 6.3.2 サービスの限定 6.3.3 SSEKMSによる暗号化を検討する 6.4 テーブルで分離or列レベル 第7章 まとめ あとがき 著者紹介 既刊一覧
目次 データ分析基盤を作ってみよう 〜性能測定編〜
第1章 制約とアーキテクチャの決定1 1.1 機能要件と非機能要件 IPの非機能要件グレード 1.2 アーキテクチャ検討へのアプローチ IP非機能要件グレードの性能・拡張性要件 性能測定をして裏付けをとる 第2章 AWサービスとその特性 2.1 Amazon Athena Athenaの性能特性 Athenaの料金体系 Athenaのそのほかの考慮点 2.2 Amazon Simpl Storage Service (Amazon S3） S3の性能特性 S3の料金体系 S3のそのほかの考慮点 2.3 AWS Glue Glueの性能特性 Glueの料金体系 Glueのそのほかの考慮点 第3章 性能測定の方法 3.1 性能測定の目的設定 3.2 性能測定をするうえで、重要なこと 測定の目的 測定環境の平準化 実際の環境に近づける 複数回の測定 メトリクスの取得 外部影響を最小限に 変更との比較 分析する 3.3 測定ツールをどうするか ディスク/ファイルシステムの性能測定 ネットワーク測定 カスタムツールの開発 テストツールのまとめ 第4章 サービスごとの性能測定 4.1 Athenaの性能測定 Athenaの検証の目的 Athenaの検証環境 Athenaの測定結果 4.2 S3のデータ転送の測定 S3の検証の目的 S3の検証環境 S3の測定結果 4.3 Glueの性能測定 Glueの検証の目的 Glueの検証環境 Glueの測定結果 第5章 測定結果に対する考察 5.1 性能測定で判明したこと Amazon Athena Amazon S3 AWS Glue 5.2 結果に対する考察 今回の検証で確認できたこと 検証できていないこと 5.3 データ分析基盤の設計への指針 第6章 まとめ あとがき 著者紹介 既刊一覧
目次 昔話で振り返るAWSの歩み
はじめに 本書の目的 対象読者 本書で得られること 本書で得られないこと お問い合わせ先 免責事項 第1章 最初の AWS サービスは何か? 1.1 AWS の何が画期的だったのか? 1.2 ジェフ・ベゾスの掟(The Bezos Mandate) 1.3 インターネット時代のmalloc S3 1.4 始まりのAWS SQS 1.4.1 S3より前に公開されていたSQS 1.5 名前を奪われた、もう一つのAWS 1.6 群衆のクラウド Amazon Mechanical Turk 1.6.1 門前雀羅化する Mechanical Turk と、その復権 1.6.2 Mechanical Turk にみる AWS の設計思想 1.7 AWS が巨大なプラットフォームになったのは何故か? 第2章 EC2 クラウドという概念をつくりあげたパイオニア 2.1 原初AWSの海に漂っていたEC2 2.2 GUI のコンソール画面なんて無い!! 統合的な CLI も無い 2.2.1 CLIすら無かった? 2.2.2 CLIのもとになったbotoとは? 2.3 EBSが無い時代のEC2 2.3.1 インスタンスストアとは? 2.3.2 インスタンスストアでの運用 2.3.3 インスタンスストアの凋落と復権 2.4 2006年にEC2を出したAmazonの決断 第3章 ストレージサービス AWS の覇権の原動力 3.1 EBS もっともハードウェアに近いサービス 3.1.1 EBS とは、どういったサービスなのか? 3.1.2 EBS 由来の大障害から垣間見える EBS の改良の歴史 3.2 S3 時代を超越したオーパーツ 3.2.1 時代のあだ花 S3FS 3.3 AWSのストレージサービス 第4章 IAM 遅れてきた仕事人 4.1 IAM 以前 4.2 VPC にみるAWSの設計ミス 4.2.1 ネットワーク権限から読み解く AWS の歴史 4.2.2 明かされる真実 4.3 IAM がAWSにもたらしたもの 第5章 Before After CloudTrail 5.1 CloudTrailがなかった時代 第6章 何もないところから始まった AWS 6.1 揃う前にリリース 6.2 記憶を記録に あとがき 著者紹介 既刊一覧
目次 IAMのマニアックな話2025
第1章 IAMの基礎と進化 1.1 AWSアカウントと IAMの関係 1.1.1 AWSアカウントと IAM 1.1.2 AWS Organizationsと AWSアカウント 1.1.3 AWS Organizationsと IAM 1.2 IAMの基本的な４つの機能 1.2.1 IAMユーザー 1.2.2 IAMグループ 1.2.3 IAMロール 1.2.4 IAMポリシー 1.3 2019年～2025年の IAM関連のアップデート 1.3.1 主なアップデートの一覧 1.3.2 IAM関連のアップデートの潮流 1.4 まとめ 第2章 AWS Organizationsと IAM 2.1 AWS Organizations 2.1.1 AWS Organizationsの概要 2.1.2 AWS Organizationsの構成要素 2.1.3 組織単位（OU）と階層構造 2.2 組織ポリシー—承認ポリシーと管理ポリシー 2.2.1 サービスコントロールポリシー（SCP） 2.2.2 リソースコントロールポリシー（RCP） 2.2.3 SCPと RCPのユースケースの違い 2.2.4 タグポリシー 2.3 AWS Organizationsと IAMの関係 2.3.1 IAMの権限に対する SCPの位置づけ 2.3.2 IAMの権限に対する RCPの位置づけ 2.3.3 ポリシーの評価ロジック 2.3.4 IAM Identity Centerとの連携 2.3.5 アカウントをまたいだ IAMロールの利用（クロスアカウントアクセス） 2.3.6 IAM Access Analyzerと Organizations 2.4 まとめ 第3章 AWS IAM Identity Centerと IAM 3.1 IAM Identity Centerの概要 3.1.1 AWS IAM Identity Centerとは何か 3.1.2 IAM Identity Centerと IAMの役割の違い 3.2 構成要素と動作の仕組み 3.2.1 インスタンス 3.2.2 アイデンティティソースの選択肢 3.2.3 許可セット（Permission Set）と IAMロールの関係 3.3 マルチアカウント時代における IAM Identity Centerの必然性と課題 3.3.1 許可セット設計の難しさとスケーラビリティの限界 3.3.2 SCIM連携・外部 IdP統合時の権限割り当て運用の複雑さ 3.3.3 IdPが1組織に1つしか設定できないという制約 3.3.4 管理主体の分散による運用の複雑化 3.4 課題を解決するための設計パターン例 3.5 まとめ 第4章 IAM Access Analyzerと CCoE 4.1 IAM Access Analyzerの基本 4.1.1 IAM Access Analyzerとは 4.1.2 外部アクセスアナライザー 4.1.3 未使用アクセスアナライザー 4.1.4 ポリシー生成 4.1.5 ポリシーチェック 4.1.6 カスタムポリシーチェック 4.2 IAM監査体制と CCoEの役割 4.2.1 組織全体で実現する IAM監査体制と CCoEの役割 4.2.2 IAM監査における代表的なチェックポイントと Access Analyzerの役割 4.2.3 リアルタイム監査の実装と組織 4.3 AIを活用したポリシー提案への夢 4.3.1 なぜ AIが必要なのか ～現状の課題と AI導入の意義～ 4.4 まとめ 第5章 AWS Verified Accessと IAM 5.1 AWS Verified Accessの概要 5.2 AWS Verified Accessの構成要素 5.2.1 Verified Accessインスタンス 5.2.2 信頼プロバイダー（Trust Provider） 5.2.3 Verified Accessグループ 5.2.4 Verified Accessエンドポイント 5.2.5 Verified Accessポリシー 5.2.6 Verified Accessのアーキテクチャ構成例 5.3 Verified Accessと IAMの関係 5.3.1 Verified Accessのユースケース 5.3.2 IAMロールと Verified Accessの関係 5.4 ゼロトラスト時代の認証認可のあり方 5.4.1 Verified Accessの役割 5.4.2 デバイス認証 5.5 まとめ 第6章 IAMベストプラクティス集 6.1 IAMベストプラクティスの変遷 6.1.1 削除されたベストプラクティス 6.1.2 追加されたベストプラクティス 6.2 ベストプラクティスに向けての対応事項 6.2.1 長期認証情報から一時的な認証情報への移行 6.2.2 Access Analyzerの活用 6.2.3 多要素認証の位置づけと管理 6.2.4 ガードレール設計 6.2.5 最小権限の実現方法の高度化 6.2.6 マルチアカウント環境のガバナンス強化 6.2.7 権限委任の体系化 6.2.8 自動化とツールの活用 6.3 AWS Well-Architected Frameworkと IAM 6.3.1 ID管理のベストプラクティス 6.3.2 アクセス許可の管理 6.4 まとめ 第7章 長期認証情報から一時的な情報へ、そして動的認可 7.1 IAMユーザーによる長期認証の時代 7.1.1 長期認証情報の特徴と課題 7.2 IDフェデレーションと IAMロールによる一時的な認証への移行 7.2.1 IDフェデレーションと一時的な認証情報の仕組み 7.2.2 一時的な認証情報がもたらす利点 7.3 コンテキストベースの動的認証・認可へ 7.3.1 属性ベースのアクセス制御（ABAC）の導入 7.3.2 コンテキストベースのアクセス制御（CBAC）に向けて 7.3.3 AWS Verified Accessの可能性 7.3.4 AWS IAM Roles Anywhereによる柔軟な認証 7.4 AWS TEAMによる承認ベースの認可設定 7.4.1 従来のスイッチロールの課題 7.4.2 TEAMのアーキテクチャと動作 7.4.3 TEAMの今後 第8章 IAMユーザーゼロへの移行ステップ 8.1 Step 1: 現状分析と移行計画の策定 8.1.1 現状の IAMユーザーの棚卸し 8.1.2 利用パターンの分類と分析 8.1.3 代替手段の選定 8.1.4 移行優先順位の決定 8.1.5 タイムラインの設定 8.2 Step 2: AWS Identity Centerへの移行準備 8.2.1 AWS Identity Centerの初期設定 8.2.2 IDプロバイダーの選定と連携設定 8.2.3 権限セットの設計 8.2.4 グループとロールのマッピング設計 8.2.5 先行ユーザーによる検証 8.3 Step 3: プログラムアクセスの移行 8.3.1 プログラムアクセスの移行戦略 8.4 Step 4: 段階的な移行実施 8.4.1 開発環境での先行実施 8.4.2 パイロットユーザーでの検証 8.4.3 グループ単位での順次移行 8.4.4 並行運用期間の設定 8.4.5 移行完了の確認 8.5 Step 5: IAMユーザーの無効化と削除 8.5.1 アクセスキーの無効化 8.5.2 IAMユーザーのログイン無効化 8.5.3 一定期間の監視 8.5.4 問題がないことの確認 8.5.5 IAMユーザーの完全削除 8.6 緊急時の代替手段の確保 8.6.1 緊急時専用アカウントの設定 8.6.2 クロスアカウントロールの設定 8.6.3 緊急アクセス手段の管理と監査 8.7 まとめ 第9章 まとめと今後のトレンド 9.1 IAMの今後の進化予測 9.1.1 IAM Identity Centerの今後の展開 9.1.2 IAMと AWS Verified Permissionsの連携 9.1.3 AWS Verified Accessとコンテキストベースのアクセス制御 9.1.4 AIによる IAMポリシーの自動最適化 9.2 それでも単一アカウントの世界は残る 9.2.1 進化の裏で残り続ける「昔ながらの IAM」 9.2.2 なぜ「昔ながらの IAM」が残るのか 9.2.3 未来と現実のバランス 9.3 IAM管理者の今後 9.3.1 IAM管理者の役割の変化 9.3.2 今後の IAM管理者に求められるスキル 9.3.3 IAM管理者のキャリアパスと学び 9.4 まとめ あとがき 著者紹介 既刊一覧