こんにちは！イーゴリです。 AWS にとって、クラウドのセキュリティは最優先事項です。(AWS公式ページ) AWS環境のセキュリティ対策としてAWSサービスを解説するよりも、まずはAWS環境の最適な設計について考える必要があります。AWS Well-Architected Frameworkを考慮しながらの設計を推奨します。AWS Well-Architected Frameworkを全部詳しく読むことをおすすめしますが、この記事では個人的に一番重要だと思う点について記載します。 とてもざっくり説明しますと、AWS Well-Architected Frameworkとは、クラウドシステムの最適な設計方法を提供するAWSのガイドラインで、6つの柱があります。この記事では基本的に「セキュリティ」の柱を技術的観点から見てみたいと思います。 AWS Well-Architected Framew

今回は、SSH接続を劇的に高速化する方法をご紹介します。たった3行の設定を追加するだけで、接続時間を10分の1に短縮できます。しかも、2回目以降の接続では認証も自動的に行われるので、パスワードやパスフレーズの入力も不要になります。 要点 .ssh/configファイルのHost *セクションに以下の3行を追加するだけです。 詳しい説明 1. ControlMaster auto この設定で、1つのSSH接続で複数のセッションを共有できるようになります。新しくSSH接続を確立するたびに認証情報を入力し直す手間が省けて、接続がぐっと速くなります。具体的には： 初回の接続時のみ認証が必要 2回目以降は既存の接続を再利用するため、認証プロセスをスキップ パスワードやパスフレーズの入力が不要になり、接続がほぼ瞬時に完了 2. ControlPath ~/.ssh/mux-%r@%h:%p Contr

【追記】この記事をきっかけに、名著「ノンデザイナーズ・デザインブック」の20周年記念特典eBookの制作に協力させていただきました。詳しくはこちらを御覧ください。 ノンデザイナーズ・デザインブック20周年記念の特典に寄稿しました デザイナーである・なしに関わらず、仕事の中で伝えたいことを「図」で説明する機会は多々あります。提案書で事業内容を説明することもあるでしょうし、具体的な数値をグラフで説明することもあるでしょう。そんな中でこんな指摘を受けたことはありませんか？ ・最終的に何を言いたいのか結論が見えないよ。 ・関係性が複雑すぎて理解しずらいんだけど。 ・要素が多すぎて全てを把握するのが大変。 ・何をどこから見れば良いの？ ・結局一番言いたいことはなんなの？ ・文字サイズがたくさんありすぎてまとまりがないね。 ・安っぽいチラシみたいでダサイなぁ。 ・全体的にバランスが偏ってて不安定。 ・

WSLパッケージの2.0.0にていくつか機能追加が行われました。ここではネットワークに加えられたミラーモードのみにフォーカスします。 [2023.10.25] ミラーモードはじめいくつかの新機能はWindows11 22H2通常版に機能開放されました。最新のWindowsUpdate適用の上、ストア版WSLをアップデートすることにより以下のオプションが.wslconfigで使えるようになります。 旧来のWSLネットワーク WSL1ネットワーク WSL1はシステムコールエミュレーションで実現されるLinux互換機能です。独自のネットワークスタックでなくWindowsそのものでした。この為、設定などに制限があるものの通信を行う分には違和感のないものでした。ただ、現在の主流は仮想マシン上でLinuxカーネルを動作させるWSL2へ移行しています。 NATモード WSL2は仮想ネットワークからNAT

最小限で基礎的なセキュリティガイダンスである「AWS Startup Security Baseline (AWS SSB)」を紹介します いわさです。 SaaS on AWS では大きく 4 つのフェーズ（設計・構築・ローンチ・最適化）で役立てる事ができるコンテンツが提供されています。 設計フェーズでは技術面からコンプライアンスに準拠したりセキュリティベースラインを考える必要があります。 これらについてベストプラクティスが提案されている動画コンテンツがあります。 その中で初期段階で実施出来ることとして次のステップが紹介されていました。 セキュリティ周りは Well-Architected Framework や Security Hub の適用から始めることも多いと思いますが、様々な制約からすぐの導入が難しい場合もあります。 そんな方に本日は上記の中の AWS Startup Secur

こんにちは、Enterprise Cloud部 ソリューションアーキテクト1課 宮形 です。先日 AWS Summit Japan 2024 へ参加するために幕張へ行ってきました。毎度ながら会場の熱量には圧倒されます。エンジニアとしてよい刺激を頂ける、毎年楽しみなイベントであります。 今回サミットでガバメントクラウド関係のセッションを聞いたり、参加者のSNS等でのレポートを拝見したりしました。目に留まったのが、AWS上のリソースに対してマイナンバー系ネットワークからDNSで名前解決する必要があることに皆様驚かれている点でした。AWS においては Route 53 Resolver インバウンドエンドポイントを利用することで、インターネットを介さずともDNSでの名前解決を実現できます。ただし、Route 53 Resolver は単体では利用できず、オンプレミスのDNSサーバーまたはActi

BeeXの榊原です。 今回はインターフェイス型VPCエンドポイントの名前解決について記事化しました。 基本単語についてそれぞれ詳細内容と、必要に応じdigコマンドの実行結果をまとめています。 ※ドキュメント引用文の日本語が所々不自然ですが、あえてそのまま掲載しています。 前提・ゲートウェイ型、Gateway Load Balancer型については本記事では触れない ・名前解決先はRoute 53 Resolverを指定。（ローカル環境からの名前解決は除く） ・エンドポイントのサービスカテゴリがAWS servicesのものとする。下記画像参照 基本用語 グローバルIPをもつAWSのサービスに対して、VPC内部から直接アクセスするための出口（引用元：Amazon VPC Blackbelt） ほとんどの AWS のサービス は、次の構文を持つパブリックリージョンエンドポイントを提供します。

マネージドサービス部 佐竹です。 本ブログでは、AWS のホワイトペーパーに新しい推奨 OU として「Business Continuity OU」が追加された件について記載します。 はじめに 2024年6月 ホワイトペーパーにアップデートがありました アップデートに関して更なる情報 バックアップアカウント Business Continuity OU (ビジネス継続性 OU) Controls （コントロール） Additional consideration （追加の考慮事項） Example structures （構成例） まとめ及び所感 はじめに 2021年8月に、学習を目的として以下のブログを記載しました。 blog.serverworks.co.jp この「AWSのホワイトペーパーから学ぶ AWS Organizations における推奨 OU 構成」は2021年6月2日にア

AWS Direct Connectと愉快なGWたちをおさらいする会 https://minorun365.connpass.com/event/285537/

自治体システム標準化・ガバメントクラウド勉強会（基礎編）での登壇資料です。 https://gov-cloud.connpass.com/event/318262/

共闘プラットフォームで真っ先に話題に出たのがSLAだ。ただ、一般的なそれとは様相が違う。あまり真剣に時間を割く必要もないだろうというのが私の見解だ。ただし、これを機に稼働率とコストの意識改革を自治体、ベンダーとにも求める。 A.1.5.1/可用性/継続性●メトリクス 稼働率 ●メトリクス（説明） 明示された利用条件の下で、情報システムが要求されたサービスを提供できる割合。 明示された利用条件とは、運用スケジュールや、目標復旧水準により定義された業務が稼働している条件を指す。 その稼働時間の中で、サービス中断が発生した時間により稼働率を求める。 一般的にサービス利用料と稼働率は比例関係にある。 ●標準選択レベル 3（99.5%） ●選択時の条件 ベンダーのサポート拠点から、車で2時間程度の場所にあることを想定。 １回当たり6時間程度停止する故障を年間２回まで許容する。 [+] コストと地理的

キホン編に引き続き、今回は自治体が主体的に決めるべきまとめておくべき要件をピックアップ。ベンダーがほぼ関与しない（できない）ので、各自治体の方々が抑えておく必要がある。要件の数としては多くなく、日頃からキチンと情報システムに関する要件をルール化されている自治体はまとめる程度でよいだろう。 E.1.1.1/セキュリティ/前提条件・制約条件●メトリクス 順守すべき規程、ルール、法令、ガイドライン等の有無 ●メトリクス説明 ユーザが順守すべき情報セキュリティに関する規程やルール、 法令、ガイドライン等が存在するかどうかを確認するための項目。 なお、順守すべき規程等が存在する場合は、 規定されている内容と矛盾が生じないよう対策を検討する。 （例） ・情報セキュリティに関する法令 ・地方公共団体における情報セキュリティポリシーに関するガイドライン（総務省） ・その他のガイドライン ・その他のルール

今回は、自治体システム標準化においてあまり話題に出ない「非機能要件の標準」を何回かに分けて執筆したい。 話題に出ないのは、おそらくあまり知られていない？のではないかと心配している。実は、「非機能要件の標準」は結構大事なのだ。ベンダーお任せの自治体も少なくないだろうが、これに関しての主役は自治体だ！ 標準仕様を満たさないと、標準準拠システムとして認めないと国は言っている。その中には、非機能要件の標準も含まれるのだ。 そして、この要件は非常にコストに影響する要件も多いのだ。 ボリュームのある内容なので、今回はキホン編。 ①非機能要件ってそもそも何だ？機能要件と非機能要件標準仕様！標準仕様！とみんなが騒いでいるのは、機能要件だ。 非機能要件を簡単に言うと、機能要件がどのように動くのかを定義しているものだ。 電卓を例に挙げると、「１+１＝」を入力したら「2」を出力と言うのが機能要件。大概、仕様に書

今回は、地方自治体の大多数を占めるであろう、共同利用方式かつマルチベンダ環境の難しさについて、説明したいと思います。 なお、特に注記が無い限り、ガバメントクラウドのCSPはAWSを想定して説明します。 １．標準準拠システムがSaaSのように使えないのは何故かデジタル庁は標準準拠システムをガバメントクラウド上に構築することについて、「SaaSのように複数ある中から自治体が好きに選んで使えるようになる」「これによりベンダロックインが無くなり、結果的に競争性が働いてコストも下がる」と説明してきました。 要するに、システム標準化により、基幹業務システムの調達が容易となり、自治体職員の負担が軽減され、職員減少による2040年問題を乗り切ることが出来るということです。 後ほど説明するように、現実にはSaaSにもロックイン要素はあります。標準化することによりそれが解消化されるかどうかの議論はさておき、デ

本記事では2023年10月6日時点で私が感じているガバメントクラウドのコスト構造の課題について記載します。 今後、制度やスキームが改善され課題が解消することを願いつつ現時点はこのような課題があったことの記録として。 この記事が課題解決の一助になれば幸いです。 デジタル庁：地方公共団体の基幹業務システムの統一・標準化 総務省：自治体情報システムの標準化・共通化 ※本記事は個人的な見解であり、所属する団体・組織の見解ではありません。念のため。 この記事で扱う課題は「ガバメントクラウドのコスト」 本記事では「ガバメントクラウド 共同利用時のコスト」にフォーカスします。 標準仕様書のFit&Gap問題（実運用との乖離）、クラウドの運用管理補助者の担い手問題（自治体の情報システム部門の過負荷問題）、移行困難団体とそれに関連する補助金の額および期限、などなど多くの課題があると思いますが本記事ではガバメ

何となくそんな気がしていましたが、最近確信するに至りました。 理由を端的にいうと、ガバメントクラウド利用基準等においては、共同利用方式のメリットの部分のみ記載して、デメリットの部分が記載されていないからです。言い換えれば、単独利用方式では発生しない隠れたコストがあるため、単独利用方式と比較して安くなることはないということです。 今回はその理由について説明していきます。また前提条件として、特に記載がない限りCSPはAWSを想定します。 １．顧客である自治体にアーキテクチャを承認してもらうための調整コストが発生する　「ガバクラの単独利用方式と共同利用方式って結局どうなの？」でも書きましたが、ガバメントクラウドの共同利用方式は、市町村としてのガバナンスを放棄し、ベンダに全権を委任する方式です。 痒い所に手が届く運用を望めない代わりに、自治体職員のマンパワーとコスト面で有利になる、そう言う説明をし

Amazon Web Services ブログ ガバメントクラウドの道案内『ASP＆運用管理補助者編』 ガバメントクラウドに関する情報は AWS も含めてさまざまな方面から毎日のように発信されており、どの情報を追ったらいいのか、何を気にするべきなのかわからなくなってくることもあるかと思います。 そこで、このブログでは「ガバメントクラウドの道案内」と題して自治体ガバメントクラウドに携わる方がそれぞれ何を検討すべきで、どの資料を確認した方がいいのかを役割別にまとめています。 本ブログは自治体に業務システムを提供するベンダーの方へ向けた「ASP&運用管理補助者編」です。 そのほかの方に向けたブログに関しては以下リンクをご参照ください。 ガバメントクラウドの道案内:『自治体職員編』 ガバメントクラウドの道案内:『統合運用管理補助者編』 ガバメントクラウドの道案内:『ネットワーク構築運用補助者編』