はじめに さくらのナレッジ編集部の法林です。 2026年10月5日(月)にオンラインイベント「さくらの夕べ CoderDojoナイト」を開催しました。本記事ではこちらの模様をレポートします。 イベントの開催趣旨 Code […]

本ブログは 2025 年 7 月 11 日に公開された AWS Blog “ Proactive strategies for cyber resilience and business continuity on AWS ” を翻訳したものです。 Amazon Web Services (AWS) は、サイバーセキュリティインシデントや、技術的な障害、自然災害といった事業継続を脅かすイベントに備えて、ワークロードを復旧できるよう準備しておくことを組織に推奨しています。この記事では、公共部門の組織が AWS インフラストラクチャを使用して、クラウド上でレジリエントなシステムを運用するためのガイダンスと戦略を紹介します。AWS がお客様に推奨している内容は次のとおりです。 サイバーセキュリティと AWS アーキテクチャのベストプラクティスに関するフレームワークを使用する マルチアカウント環境を実装する AWS 環境とワークロードのデプロイに Infrastructure as Code (IaC) を使用する プライマリワークロードとは異なるアベイラビリティーゾーンまたは リージョン に復旧用アカウントを準備する すべてのアプリケーションコード、IaC コード、設定ファイル、その他の依存関係を復旧用アカウントに配置する 復旧用アカウントにデータをバックアップする戦略を定義する 復旧用アカウントで、ユニットテストとワークロード全体のテストを自動化する 確立されたフレームワークを使用する ランサムウェアなどのサイバーセキュリティインシデントが増加し続ける中、公共部門の組織は、サイバーセキュリティリスクをより適切に管理するためのガイダンスとして、 NIST Cybersecurity Framework (CSF) 2.0 などのフレームワークを参考にしています。このフレームワークは 米国国立標準技術研究所 (NIST) が策定したものです。CSF はサイバーセキュリティの成果を機能 (統治、識別、防御、検知、対応、復旧) ごとに整理していますが、NIST はその成果を達成する具体的な方法までは規定していません。 より具体的なガイダンスについては、「 AWS Blueprint for Ransomware Defense 」などのリソースを参照してください。このリソースでは、具体的な AWS サービスを CSF の各機能にマッピングしています。AWS でのアーキテクチャ設計のベストプラクティスを深く理解するには、 AWS Well-Architected フレームワーク が役立ちます。このフレームワークは 6 つの柱に沿ってベストプラクティスを詳しく解説しており、クラウドアーキテクトが AWS 責任共有モデル に従って、さまざまなアプリケーションやワークロード向けに、安全で高性能、レジリエントかつ効率的なインフラストラクチャを構築できるよう支援します。さらに、これらのフレームワークを補完するのが AWS Security Reference Architecture (AWS SRA) です。AWS SRA は、AWS の推奨プラクティスに沿って AWS のセキュリティサービスを設計、実装、管理するのに役立ちます。この記事では、CSF と AWS Well-Architected を橋渡しする形で、サイバーセキュリティイベントや災害からの復旧に備えるための重要なパターンを紹介します。 AWS でマルチアカウント戦略を実装する AWS では、ベストプラクティスとして、マルチアカウント戦略に基づいてクラウド環境を構築することを推奨しています。このようにマルチアカウント戦略に基づいて構築した環境は ランディングゾーン とも呼ばれます。 AWS Organizations を AWS Control Tower または Landing Zone Accelerator on AWS と組み合わせて使用すると、管理と自動化が容易な環境を構築できます。複数の AWS アカウントを使用すると、アプリケーションとデータを分離して管理しやすくなり、環境内での意図しない横方向の移動 (ラテラルムーブメント) を排除できます。 マルチアカウント戦略の一環として、AWS は AWS IAM Identity Center を使用してアイデンティティを一元管理することを推奨しています。AWS 外部の ID プロバイダーを IAM Identity Center と統合することも可能です。ただし、復旧時にはルート認証情報を使用しなければならない場合があります。 AWS では、AWS アカウントへのルートアクセスは必要な場合にのみ使用することを推奨しています 。アカウントの乗っ取りや不正アクセスを防ぐために、ルート認証情報は適切に保護する必要があります。AWS は 2024 年 11 月に、ブログ記事「 AWS Organizations を使用するお客様のためのルートアクセスの一元管理 」で、ルート認証情報を一元管理するための新機能を発表しました。ルート認証情報を一元管理することで、長期間有効なルート認証情報を削除し、認証情報が意図せず、または不正にリカバリされることを防止できるため、AWS 環境全体のセキュリティポスチャを強化できます。 自動化によって AWS インフラストラクチャを構築する AWS は、DevSecOps の重要な原則として、すべての AWS インフラストラクチャを IaC でデプロイすることを推奨しています。IaC を使用すると、インフラストラクチャを迅速に反復改善できるほか、一貫性と再現性の向上、設定ミスの削減、バージョン管理も実現できます。復旧の観点で特に重要なのは、IaC がインフラストラクチャのドキュメントとしても機能することです。IaC は、事業継続を脅かすイベントからの復旧と、それに備えたテストを迅速化します。これにより、新しい AWS アカウントや AWS リージョンにインフラストラクチャをすばやくデプロイできます。 AWS のサービスは IaC を前提に設計されており、組織のニーズに合わせてさまざまな IaC ツール から選択できます。AWS は、 AWS CloudFormation や AWS Cloud Development Kit (AWS CDK) などの選択肢を提供しています。AWS CloudFormation ではテンプレートを使用してインフラストラクチャを定義でき、AWS CDK では使い慣れたプログラミング言語でクラウドリソースを定義できます。また、AWS CloudFormation では 既存のインフラストラクチャからスタックを作成 することもできるため、IaC への移行が容易になります。アプリケーションレベルでは、 AWS サーバーレスアプリケーションモデル (AWS SAM) を利用できます。AWS SAM は、IaC を使用してサーバーレスアプリケーションを構築するためのオープンソースフレームワークです。AWS は HashiCorp Terraform もサポートしています。HashiCorp Terraform は、複数のクラウドサービスプロバイダーにまたがるリソースとオンプレミスのリソースの両方を、人間が読める形式の設定ファイルで定義できる IaC ツールです。この設定ファイルは、バージョン管理、再利用、共有が可能です。 どのツールを使用する場合でも、IaC はリソース名、AWS リージョン、IP 範囲などを変数化して開発できるため、AWS アカウントやリージョンをまたいでコードを簡単に再利用でき、復旧プロセスを迅速化できます。IaC コードは、GitLab などのソースコードリポジトリに保存してください。より迅速に復旧できるよう、独自の DevSecOps パイプラインを構築することも、AWS 規範ガイダンスに従って標準化することもできます。 DevOps Pipeline Accelerator (DPA) は、前述のツールを使用して、アプリケーションやインフラストラクチャをデプロイするための 継続的インテグレーションと継続的デリバリー (CI/CD) パイプライン全体の構築に役立つテンプレート群で構成されたソリューションです。IaC の詳細については、 Infrastructure as Code のホワイトペーパー を参照してください。 復旧先を準備する アイデンティティの侵害などのサイバーセキュリティインシデントに備えて、AWS は前述のマルチアカウント戦略を活用し、復旧用のアカウントを個別に用意することを推奨しています。AWS アカウント内のアイデンティティはロールに基づいて管理すべきですが、悪意のある攻撃者がルートアクセスを取得しているか、自身の権限を昇格させることができる場合は、同じアカウント内のバックアップも侵害される可能性があるためです。 技術的な障害や自然災害への対策として、可能性は低いものの、 AWS アベイラビリティーゾーン が利用できなくなるシナリオからワークロードを保護できます。リージョン内でアベイラビリティーゾーン単位の復旧を行う場合は、復旧用のアベイラビリティーゾーンが、ワークロードのデプロイ先とは別のゾーンであることを確認してください。そのためには、アカウント間で一貫したアベイラビリティーゾーン ID (AZ ID) を使用します。 AWS は、アカウントごとに AZ の名前をランダムに割り当てます 。別のアカウントのアベイラビリティーゾーンを復旧に効果的に使用するには、リージョン内の すべてのアカウントで一貫した AZ ID を使用 してください。この方法により、同じリージョン内の 2 つ以上のアベイラビリティーゾーンにワークロードを分散デプロイしてレジリエンスを確保しつつ、復旧用には別のアベイラビリティーゾーンを使用できます。一貫した AZ ID を使用すれば、復旧用のアベイラビリティーゾーンを、すべてのワークロードのデプロイ先とは確実に異なるゾーンにできます。 訳注: 2025 年 11 月以降に作成されたアカウントでは、従来はアカウントごとに AZ 名の対応がランダムだったリージョンでも、すべてのアカウントで同じ AZ 名が同じ AZ を指します。それより前に作成されたアカウントでは、従来どおり AZ 名がアカウントごとに個別に対応付けられているため、アカウント間で AZ を揃えるには引き続き AZ ID を使用します。参照: AZ IDs – AWS Regions and Availability Zones 次の図は、AZ ID を使用したワークロードアカウントと復旧用アカウントのアーキテクチャを示しています。 図 1. アベイラビリティーゾーン ID を使用したワークロードアカウントと復旧用アカウントの例 より広範囲に及ぶ技術的な障害や自然災害に対するレジリエンスを確保するには、マルチリージョンでの復旧を選択することもできます。AWS は、可能であれば、復旧用アカウントに別のリージョンを使用することを検討するよう推奨しています。例えば、米国東部 (バージニア北部) リージョン ( us-east-1 ) をメインに、米国東部 (オハイオ) リージョン ( us-east-2 ) をバックアップ先にする構成です。少なくとも、データは別のリージョンにバックアップすることを AWS は推奨しています。クロスリージョンのバックアップ先を使用する場合、別のアカウントでバックアップデータを復号できるよう、 AWS Key Management Service (AWS KMS) を使用した暗号化キーの戦略を検討する必要があります。 なお、リージョン間のデータ転送料金はアベイラビリティーゾーン間よりも高くなる可能性があります。この点も、バックアップ先の戦略全体を検討する際に考慮してください。 バックアップ戦略を定義し、自動テストを実装する AWS は、クラウドベースのソリューションに合わせてバックアップ戦略を策定することを推奨しています。前述のとおり復旧先を準備したら、 AWS Backup を使用してワークロードデータを復旧用アカウントにバックアップできます。AWS Backup は、IaC、インフラストラクチャの設定データ、アプリケーションコード、アプリケーションの設定を復旧先に保存する用途にも使用できます。ほとんどのシナリオでは、ワークロードの復元にこれらすべての種類のデータが必要になります。クラウドベースのコードリポジトリを使用している場合は、十分なバックアップ機能がそのソリューションに既に備わっている可能性があります。 バックアップしたデータが実際に使用できるかを検証するために、AWS は復旧用アカウントで自動テストを実装することを推奨しています。例えば、バックアップの完了後に実行され、バックアップを正しく読み取れることを確認する自動プロセスを実装すると、ランサムウェアなどの脅威に対する効果的な緩和策になります。こうした攻撃への対策をさらに強化するために、バックアップしたすべてのコンポーネントについて複数のバージョンを保持し、必要に応じて古いバージョンのバックアップを復元できるようにしておくこともできます。また、バックアップ戦略の一環として、 AWS Backup Vault Lock などの機能を使用したイミュータブルなバックアップの採用を検討するのもよいでしょう。 バックアップと IaC の戦略の一環として、ワークロードに必要なコンポーネントが復旧先に保存されていることを確認してください。対象には、IaC コード、インフラストラクチャの設定データ、 Amazon マシンイメージ (AMI)、アプリケーションコード、アプリケーションの設定が含まれます。このプロセスは、DevSecOps と IaC の戦略全体に組み込む必要があります。DevSecOps パイプラインで変更が行われたときに、これらすべてのコンポーネントのバックアップをトリガーする自動プロセスを実装すれば、復旧用アカウントのバックアップを常に最新の状態に保つことができます。パイプラインの変更が頻繁に発生するシステムでは、毎日など定期的に実行される自動バックアッププロセスを選択することもできます。 復旧用アカウントの準備、IaC の実装、バックアップ戦略の確立が完了したら、復旧用アカウントでワークロード全体をテストすることを AWS は推奨しています。復旧用アカウント内の IaC コードとバックアップを使用して、そのアカウントでワークロード全体を定期的に構築してください。多くの場合、既存のコンポーネントテスト、統合テスト、ユーザー受け入れテストのスクリプトを、定期的な事業継続訓練に活用できます。このようなテストによって復旧機能の有効性を検証でき、事業継続を脅かすイベントが発生した場合にワークロードを復旧できることを確認できます。 まとめ この記事で紹介したベストプラクティスに従うことで、公共部門の組織は AWS の機能を活用して、事業継続を脅かすイベントからの復旧に備えることができます。さらに詳しいガイダンスについては、AWS アカウントチームとソリューションアーキテクトにお問い合わせください。 Devin Gordon Devin は Amazon Web Services (AWS) のプリンシパルソリューションアーキテクトとして、米国連邦政府の文民機関を支援しています。AWS ではセキュリティを専門としており、お客様が新興テクノロジーを活用しながら安全な環境を実装できるよう支援することに情熱を注いでいます。旅行が好きで、特にスキューバダイビングやハイキングなどのアウトドア活動を楽しんでいます。 Henrik Balle Henrik は AWS のプリンシパルソリューションアーキテクトとして、米国の公共部門を支援しています。機械学習から大規模環境でのセキュリティとガバナンスまで、幅広いトピックについてお客様と緊密に連携しています。余暇にはロードバイクやオートバイを楽しむほか、自宅のリフォームに次々と取り組んでいます。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

はじめに こんにちは！丹羽と申します。 初めてのブログ投稿です。よろしくお願いします。 今回は私がサイオステクノロジーに入社して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 .