もともとBranch protection ruleを設定するためだったのだが、いろいろ調べてみると、これはブラウザからやるほうが早いという結論になってしまったので、今回はお蔵入りに。
ただログインまでは持って行ったので、いずれ使うこともあるかもしれないということでメモしておく。
gh pr statusでインストールできていることを確認gh auth loginでログインするこんな感じ。これで無事ログインできた。
> gh auth login ? What account do you want to log into? GitHub.com ? What is your preferred protocol for Git operations? HTTPS ? Authenticate Git with your GitHub credentials? Yes ? How would you like to authenticate GitHub CLI? Login with a web browser
便利そうなんだけどなあ。
プログラミングの手助けに、と思ってCopilotを導入したところ、なんと記事のライティングも手伝ってくれるようになった。
プログラミングを手助けしてくれるCopilotだが、実は記事のライティングにも使える。というか、使えた。
これがなかなか悪くない。たとえば、この記事のまさにここで「こうして」と書くと
こうして書いているのはCopilotのおかげだ。これはまさにAIがライティングに活かせる時代だ。
とまあ、ここまで補完してくれる。Copilot氏はかなり自信家であるご様子だが、最新鋭のAIであるから、それくらい自己評価が高くてもよいのかもしれない。
結論から言うと、それなりの実用度、と言ったところである。たまにジャマになる。おかしな方向に文を持っていかれることもあるし、ループしているのか同じ文をずらずら並べる奇妙な挙動を示すこともある。
だが、上手く先回りしてくれて楽ができることもよくあり、すくなくとも自分はこの機能をオフにしたいとは思わない。
これはかなりの実用性だ。
（推敲前だが、ここでCopilot氏はこう合いの手を入れた！）
どのような分野でも対応できるのかはわからないが、少なくともIT系の記事を使う分には悪くない補完をしてくれる。
ついにAIもここまで来たか、と感慨深いものがある。進化の速さには驚くばかりだが。
Copilotはまだβ版で、まだまだ不完全な部分がある。しかし、これからどのように発展していくのか、楽しみである。
（↑これは、最後になにか語らせようと思って、「copilot」と打って後を補完させたもの。実際にはすでにCopilotはGAしている。時折古い情報や間違った情報を混ぜこんでしまう点には注意が必要だ。本人の中ではまだβ版なのかもしれないが）
このところブログの更新が滞っているため雑記だけでもと思い、記す。
タイトルの通り、マイナンバーカードの健康保険証利用を登録した。ポイントに釣られた。
それ自体は私事なのだが、驚くべきことに登録が簡単だった。手続きが数分で終わった。驚くことか、と思うかもしれないが、もちろんだ。かつてこの手の公的サイトは利用者の利便性を無視するのが通例であった。劣悪なUXに耐えて必要な手続きに辿りつける、ある種の苦行者だけが利用できるものであった。だから今回も１時間２時間は覚悟していた。それが数分で終わったのだ。驚かないことがあるだろうか。
前の記事の通り公官庁のデジタル化の進捗はあまりよくないという話を読んだばかりだったので、これは嬉しい誤算だ。UXは大いに改善されていた。公官庁のDX化はどうやら本気のようだ。ありがたいことである。
ちびちびとAWS系の技術同人を書き進めているわけだが、お陰でブログの更新が滞っている。さすがに両方書くのは厳しい。ただこれはこれで困るので、書いている内容を元にブログ記事しようかと思う。書き方を合わせる時間がかかるが――ブログはである調、同人はですます調――しかたない。
すこしくらいインフレをヘッジしとくべか、というわけで物価連動国債を扱う投信を買うことにした。といってもそんな大きな額にはしないので、本当にちょっとした保険といったところ。むしろヘッジコストのほうが嵩む可能性もある。
だが、この場合そうなったほうがむしろ総合的に見て幸せだろう。このような警戒は役に立たずに終わるのが一番だが、はてさて。
ある人から近所にある真言宗のお寺がなかなか良いと聞き、見学に。護摩壇を生で見ることができプチ感動。別段お寺に詳しいわけではないのだが、禅系のお寺と密教系のお寺は同じ仏教系の施設でもかなり趣が違うように感じられる。リモートでかなりのことができるようになった昨今だが、実地を見なければ気づかないこともまだまだあるもの。
『2040年の日本』を読んだ。落ち着いた筆致の良書。しかし、淡々と事実を押さえるだけでかくもシビアな内容になるか、と驚く書でもあった。
暗い話題が多かったが、そうならざるを得ないだろうな、という印象。
世情が厳しさを増す中で、自分になにができるか、またなにをどこまですべきであり、なにをすべきでないか、というテーマは、自分含めて多くの日本人が直面することになりそう。
日頃当然のように利用しているAWS VPCを、整理の意味も兼ねて改めて考え直してみたい。
なおタイトルにIssueとついているのは『イシューからはじめよ――知的生産の「シンプルな本質」』を読んでいて感化されたため。
考えながら書いているので、冗長になるのはお許し願いたい。
そもそもVPCを用意しないといけないのはなぜか。この疑問を考えるにあたっては、比較したほうがわかりやすかろうということで、VPCが無い場合とある場合でどう違うのかを比較して考えてみる。
VPCがあるとなにが良いのだろうか。もしくは、ないとどうなるのだろうか。
まあ大体ここに書いてある通りではあるのだが、ＶＰＣのメリットは概ねセキュリティの維持にあると言ってよさそうだ（IPアドレスなど、当てはまらないものも若干あるが）。データ破壊などを防ぐことで「可用性」を、不要な通信をシャットアウトすることで「機密性」を、それによって間接的に「完全性」を得られるわけだ。
してみると、VPC構築の本質的な価値も同様に考えていい。３要素のうち特に可用性、機密性がポイントだろう。
可用性を維持できるようMultiAZを採用したり、通信ログを監視したり（間接的な繋がりだが）する。
そしてまた、通信権限を必要最小限にとどめるために、サブネットを切ったり、SecurityGroupを細かく設定したり、NATゲートウェイやVPCエンドポイントなどの外部接続のための仕組みを用意したり（これがないと全部Publicにおかざるを得ないわけだから、これも通信権限を限定するための補助的な仕組みと言っていい。事実、ノードを全部Public Subnetに置いて通信も公開ネットワークをどんどこ飛び回っていいなら、NATゲートウェイもVPCエンドポイントも必要ない）する。
その設計はセキュリティ確保に寄与するか？
それがVPC設計のキモと言っていいだろう。
もちろん、サブネットで確保したアドレス範囲が狭すぎて必要なノードが配置できない、なんてのは困るから、セキュリティしか考慮する点がないわけではないのだが。
かねてから技術同人を書いてみたいと思っていたので、ついに実行することにした。
のだが、エイヤでやろうとしたら行き詰った。
しょうがないので改めてちゃんと計画を練って出直すことにしたので、その検討時のメモを残しておく。後で見直して「こんなことも考えてたな」みたいな昔を懐かしむネタになるかもしれない。
それなりに業界に長くいるし（といっても二十年に満たないくらいだが）、書けることくらいあるだろう、と思っていたがこれが意外に難しかった。
まずAWS Well-ArchitectedやThe Twelve-Factor AppのようなBest Practice的なものはどうかと思ったが、これは自分がそもそも書けない。言うてもエンジニアリングに関わる中で自分なりのBestは追ってきたわけだが、それは自分が置かれた環境に最適化したものなのであって、汎用のBestPracticeとしてぶちあげられるかというと、それはまた別の話だ。あと既存のBestPracticeがよくまとまってるんだからそれでいいじゃんという説もある。
ではこれまで関わってきた他社プロジェクトの内容についてはどうか。なんてことは考えるまでもなく、もちろん書けない。ビジネスマナー上NGだ。
では自分でやってみた系はどうか。これは悪くない。ただ当たり前ながら、まずやってみる必要がある。すぐ書き始めるというわけにいかない。いずれやってみたいが、今回の件に間に合わない。
というわけで折衷案に行きついた。"WEBアプリケーションをド新規で作ると仮定して、その場合どんなインフラを構築し、運用手段を用意するか"である。商業誌でもよくある形式である。だがまた変わるかもしれない。
結論、構成は抽象的なSummaryから具体的なDetailに落としていく方向で行くことにした。要旨を先に述べたほうが何が言いたいのかわかりやすいので自分好みだからである。
つまり全体像はこんなイメージで
さらに個別のテーマは1)構築する順 2)重要性順で２段階に並べ替える。たとえばテーマがアプリ実行用環境ならこんな感じ。
でもって、それらの項目はやっぱり抽象的なSummaryから具体的なDetailに落としていく。
だいたいこれでわかりやすくなるのではなかろうか。
やさにちチェッカーや校正ツールなどを使う。あとできれば他の人にも見てもらえるといいのだけどなあと思いつつ、まずはモノを作ってから物を言おうということで、当面は自分ひとりでガンバル。
書いてから考える。
マーケティングガン無視だが同人なら許されるであろう。
KMSを改めて復習したくなったので、自前のメモがてらに記事にしてみる。
データの暗号化やデジタル署名に使用するキーを作成して管理するマネージドサービス。
データの暗号化や複合などの処理まで行うというよりは（※）、キーの管理をメインとしているサービスである。
暗号化に使うキー（ファイル）の保管は、がっちりセキュリティを守ろうとすると難題で、「盗っ人に入られたらどうするんだ」なんてことまで気にしないといけなくなる。そういうことをしなくて済むのは大変ありがたい。
※ データキーの生成、暗号化、復号はKMS側で行う。エンベロープ暗号化戦略を採用しているため。
AWS KMS はデータキーの生成時、即座に使用 (オプション) できるプレーンテキストのデータキーと、データと共に安全に保存できるデータキーの暗号化されたコピーを返します。データを復号する準備ができたら、最初に AWS KMS を要求して、暗号化されたデータキーを復号します。 AWS KMS はデータキーを生成、暗号化、復号します。ただし、AWS KMS はデータキーの保存、管理、追跡、またはデータキーの暗号化オペレーションを実行しません。AWS KMS の外部でデータキーを使用して管理する必要があります。データキーを安全に使用する方法については、「AWS Encryption SDK」を参照してください。（AWS KMS の概念）
また、暗号キーは２種・２用途に細かく分けられている。
KMSで管理できるキーには、単一の暗号化キーを使うSymmetric、秘密鍵と公開鍵を使うAsymmetricの２種がある。それぞれ1)データの暗号化・複合 2)改ざん検知 に用いるので、２×２で４つの組み合わせがある。
Asymmetricのほうは公開鍵ももちろん取得できる。こんな感じのテキストデータである。
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhFAAOCAQ8AMIIBCkiG9w0BAQEgKCAQEAjQt/KIm5oEDQqy0pqzww
uaToJDAe1QPi45tD9D1+bzr0FSPo5LUrjEBlQ0gztLLFSibr10IEi9p0+QaNqEE7
8k9iTw/fWtHJpp+6z4gSq/rpARNkZSjZLXLdpAZlBNyjx9H8x8eKKEg0hZXkSiZR
piYEcsCVm1ikh4LHwXfeit7z6X2WTmQzeRjjS1Xj1qne22oBZb3Ar8KIq5a3xnVp
WAqPIAMqb1J9lawPg6QTP8SFd5PC9gbrwP6T+NRmUtY5Q5TQ/zHcGg0PXgqa/NjX
Eq4a5bYmPit4o4+WFaJXJBrO32DW35gcuhIKB0Ulnp7Lagkyb8CWZM8MswYV80ii
/QIDAQAB
-----END PUBLIC KEY-----
なお言うまでもなくダミーであり、私はこの公開鍵を用いていない:-)
AWSで使う場合、マネージドサービスが使うサーバーサイド暗号化と、自分たち利用者側で勝手に行うクライアントサイド暗号化がある。前者はKMSのキーを構築時に指定すれば透過的に使える一方で、後者は自らアプリケーションの中で処理を行う必要がある。
もちろんどちらもフリーランチではなく、負荷が増す。そのため数年前まで、クライアントサイド暗号化はもちろん、サーバーサイド暗号化も、意識の高い現場（もしくは業務上より高いセキュリティが必要とされる業務に携わる現場）でもないと割合省略されがちだったと思うが、昨今ではむしろ行って当然のものに変わりつつある印象である。これまでよりもKMSの重要性は高まっていると考えるべきだろう。
鍵の漏洩と消失が起こると悲惨なことになる。漏洩するとクラッカーが複合も改竄もできるようになってしまいうる。消失すると、そのキーを使っていたデータは使うことができなくなる。
従って、漏洩させないよう管理を厳にするとともに（最小権限の原則を実現するためのKMSでのアクセス制御）、漏洩しても被害を限定し（KMSのローテーション機能や異常検知の仕組みの整備）、かつトレーサビリティを確保すべく操作ログも残さないといけない（CloudTrailによる証跡の保存と、S3のオブジェクトロックやMFA deleteによる保護）。
また、うっかりミスで削除してサービスが復旧不能（本当にありえる！）にならない仕組みもいる。削除予定の鍵が使われたら通知する仕組みがこれにあたる。
CloudHSM というものもある。KMSでも歯が立たないほど際立って厳しいセキュリティ要件に対応するためのもの。
専用ハードウェアで処理を行うため大変堅牢なのだとか。ただし、それだけにお高い。
