本文の内容は、2023年3月21にNIGEL DOUGLAS が投稿したブログ（https://sysdig.com/blog/terraform-security-best-practices）を元に日本語に翻訳・再構成した内容となっております。 コードとしてのインフラストラクチャ ー(IaC) を使用する場合、Terraform はデファクトのツールです。 リソース プロバイダーに関係なく、組織はそれらすべてを同時に操作できます。 コンフィギュレーションエラーがインフラストラクチャー全体に影響を与える可能性があるため、疑いの余地のない側面の 1 つは Terraform のセキュリティです。 この記事では、Terraformを使用するメリットを説明し、いくつかのセキュリティベストプラクティスを参照しながら、Terraformを安全な方法で使用するためのガイダンスを提供したいと思います。

はじめに こんにちは。 みなさんZappierやIFTTTを使ったノーコード自動化は好きですか？ 僕は業務の効率化や自動化が好きなので、こういったツールは今まで興味を持っていましたが、料金的なところで二の足を踏んでいました。。。 最近のSaasサービスの値上げラッシュ。特に海外のツールはどんどん月額設定が高くなりますし、為替の影響で高くなります。 ですので、結局、自動化したいことはコードを書いたりエンジニアの知識をフル活用して自動化しちゃいます。笑 今回は、そんなエンジニアのみなさんに向けて、n8nというローコード自動化ツールをご紹介しようと思います。 n8nとは 技術者向けのワークフローの自動化 API と戦うことなく、複雑な自動化を 10 倍速く構築 スクリプトのスパゲッティを苦労して過ごした日々は終わりました。その他すべてに柔軟性と UI が必要な場合は、JavaScript を使用

前置き 本記事は特定のサービスのリバースエンジニアリングを推奨するものではありません。 リバースエンジニアリングの学習を目的とした利用を前提としています。 また、この記事は私が2021年に公開したWrite-upの日本語訳です。 内容は2018年に行ったリバースエンジニアリングの結果に基づいていますが、2020年にはいくつかの仕様が変更されたことに留意してください。 Shh 0. LINEの解析について こんにちは、リバースエンジニアリングについて学んでいる らと です。 各国にはそれぞれ人気なメッセージングアプリがあると思いますが、私の国、日本ではLINEが最も多くのユーザーに利用されています。 私はLINEの通信プロトコルに非常に興味がありましたが、LINEはOSSアプリケーションではありません。 そのため、LINEをリバースエンジニアリングすることに決めました。 1. LINEってな

今回エントリーするのは、山本芳彦『数論入門』岩波書店だ。この本は以前にも、このエントリーで紹介しているが、今回は違う観点から推薦したいと思う。 数論入門 (現代数学への入門) 作者:山本 芳彦 岩波書店 Amazon ゆえあって、最近またこの本を読み始めたのだが、面白くて遂にほぼ全部読んでもうた。そして全体を読破すると、この本がもくろんでいること、この本の特質がひしひしつと伝わってきた。ひとくちに言えば、この本は、「ドラマの優れた総集編を観るようなすばらしい内容」ということなのだ。 ドラマの総集編って、全12話を4話ぐらいでかいつまむ。もちろん、圧縮しているので、カットされたエピソードもあるし、ナレーションで進めちゃう場面もあるし、スルーされるキャラもある。でも、優れた総集編では、本編より本質が浮き彫りになり、面白さが倍増になることも多い。この本は、数論の総集編として、そのメリットがみごと

※この投稿は米国時間 2023 年 2 月 18 日に、Google Cloud blog に投稿されたものの抄訳です。 Cloud Run を使用すれば、デベロッパーは、Google のスケーラブルなインフラストラクチャ上で実行されるサーバーレス環境に本番環境のウェブ アプリケーションと API を簡単にデプロイできます。開発チームは Cloud Run を活用して開発のアジリティを向上させ、迅速に反復処理できますが、多くの場合、インフラストラクチャのセキュリティ体制が見落とされています。十分な注意が払われていないセキュリティの側面として特に注目すべきなのが、アクセス管理と最小権限の原則です。 最小権限の原則とは、あるリソースに対してその機能に必要なリソースのみへのアクセスを許可することを示します。この原則は、ID の侵害によって攻撃者に幅広いリソースへのアクセスが許可されるリスクに対応

はじめに 先日新たにAWS WAFを導入をする機会があり、その際に改めて知ったWAFの知見について、より実用的な項目に絞ってまとめてみました。 いまや非常に多くの種類があるWAFルールの情報や、マネージドルールの便利さについて言及された技術ブログはよく見かけます。しかし導入時の設定内容のポイントや、「そもそも何を検討すべきか？」をまとめた記事は多くないと感じていたため、自分で書くことにしました。 ※ 以降ではすべてAWS WAFv2を想定した話であり、v2を省略してAWS WAFと書いています。 1. WAFルール・ルールグループの選択 AWS WAFの導入時に最初に考えることとして、ルールの選定や紐付けるリソース、動作モード、ログ出力などがあります。 ルールの選定は、つまるところ 「WAFで何がしたいのか？」 を決定することに等しく、多数のルールグループの中から、最適な複数のルールグルー

はじめに build own xってなに？という方がいらっしゃると思います。 下記ページにあるような自作～みたいなやつのことを指しています。 自作OSとかDBとかとにかく様々な種類があるんですが、僕がやってみて良かったなぁと感じたものだけ紹介します。(一部やってないけど良さそうなのも紹介します。) 難易度を星5を最高として書いていきます。 言語は日本語 or 英語です。 コンパイラ writing interpreter in go 形態:本 言語: 日本語、英語 コンパイラ系なら一番初めにおすすめなのは間違いなくこれ。 日本語版では「Go言語でつくるインタプリタ」という題で出版されています。 外部に依存するライブラリを一切使わないのが特徴でスクラッチで書きます。 語り口調も平易でわかりやすく、コンパイラ？インタープリタ？という方にもおすすめ。 Monkeyという言語を実装するのですが、既

Linuxにおけるデバイスファイルはデバイスをファイルという概念を通して扱えるようにしたものです。デバイスファイルは通常のファイルと同様に読み書きを行うことができます。しかし実際には、その読み書きはデバイスドライバを通じてデバイスの制御に変換されます。 この記事では、デバイスファイルへの読み書きがどのようにデバイスの制御に変換されるのかを説明します。デバイスファイルはデバイスドライバとファイルの2つのコンポーネントに依存したものであるので、最初にデバイスドライバ、次にファイルについて説明し、最後にデバイスファイルがどのようにデバイスドライバと結び付けられるかを解説します。 この記事の内容は主に詳解 Linuxカーネル 第3版及びhttps://github.com/torvalds/linux/tree/v6.1によります。 目次 デバイスドライバ デバイスドライバの実例 read_wri

こんにちは。システムセキュリティ推進グループの花塚です。本記事は、AWSにおける脅威検知のために取り組んだ内容について紹介します。 AWS上で脅威検知といえば、GuardDutyなどのサービスを使って実装するのが一般的だと思いますが、仕組みは構築できても以下のような悩みを持たれることはありませんでしょうか。 仕組みは完成したけど、結局アラートが対応されずに放置されている 限られた人的リソースの中で大量のアラートを捌ききれない 仕組みは構築できても、上記のような運用面に関する難しさを感じる事は少なくないと思います。そこで、この記事では、構築した仕組みとその仕組みを生かすまでの運用方法の変遷について詳しくご紹介します。 大規模なクラウド環境に対して、セキュリティをスケールさせたい方にとって少しでも参考になれば幸いです。 目次 背景 構築した仕組み 運用とその変遷 最後に 背景 話を進める前に、

600ページを超える書籍である「データ指向アプリケーションデザイン」の要点を最近の話題を交えながら解説します。 Data Engineering Study #18 の発表資料です プレゼンテーション https://www.youtube.com/watch?v=ZiKWXc0fSCw イベントURL https://forkwell.connpass.com/event/269125/ データ指向アプリケーションデザイン https://www.oreilly.co.jp/books/9784873118703/

一つのデータパイプラインの中で、やりたいこと毎に小さいパイプラインを作る データ変換処理のパイプラインと言うのは、放置しているとどんどん複雑になる傾向にあります。 そこで、ある程度統制するため、層に分けるアプローチがよくとられています。 しかし、この層に分けると言うのは案外難しく、データ更新の頻度や鮮度の管理に課題があります。 今回はやりたい事ごとに都度パイプラインを作り、その中で他にも使えるテーブルを再利用してテーブルの乱立を防ぐ、方法を考えました。 このアプローチの実現にはいくつか制約があります。この記事では、直面している課題、アプローチの利点、そしてdbtを用いた実装方針について記載していきます。 この手法が着目している課題 データメッシュと言うと、大企業におけるデータマネジメントに近い印象を持つと思います。 上記の記事では、大企業における部署のような単位をドメインとしているので、組

2022年に発表され話題となっている Cloudflare D1、未だアルファ版のようですがすでにいろいろと触ってみた方も多いかと思います。 自分はVantiqという会社で自社製品であるVantiq Platform 上のアプリケーション開発・アーキテクチャ設計を業務として行っているわけですが、様々なクラウドサービスと自社製品をどう組み合わせたら面白いことができるかなと日々考えたりもしています。 Cloudflare D1 も気になっていたところで、公式のチュートリアル をやってみて、実際に手を動かして概要を理解してみたいと思います。 Cloudflare D1 とは Cloudflareが提供する、エッジロケーションに配置されたSQLiteベースのリレーショナルデータベースです。 概要は公式ドキュメントや他に秀逸な記事があるので読んでいただくとして、個人的に興味深いのは 分散データベース

前振り 全国の暗号を使うエンジニアの皆さんこんにちは。今日は暗号移行とRSA暗号の話をしたいと思います。まず暗号を利用している皆さんであればCRYPTRECの「電子政府推奨暗号リスト」のことはご存じですよね！（言い切るw） CRYPTRECから2022年7月（昨年夏）に暗号強度要件（アルゴリズム及び鍵長選択）に関する設定基準（PDF直リンク）が公開されました。この中では暗号のセキュリティ強度で各種暗号と鍵長が整理されています。セキュリティ強度はビットセキュリティと呼ばれるビットサイズ（共通鍵暗号の場合のビット長）で区分されます。暗号アルゴリズムが違ってもセキュリティ強度で比較ができるということですね。例えば現在一般的に良く使われているセキュリティ強度は112ビットセキュリティが多く、これにはデジタル署名であればRSA暗号の2048ビットやECDSAのP-224等が含まれます。今日は公開鍵暗

export type Bookmark = { id: number; url: string; comment: string; }; このファイルには型しか書いてありませんね。ということは、「型定義ファイル」として bookmark.d.ts という名前にするべきでしょうか。実はそうではなく、この場合は bookmark.ts とするべきです。 「型定義ファイル」とは、「どこか別の場所にある実装に型をつけるためのファイル」です。たとえば、以下のファイルは「どこか別の場所にある実装」に型をつけているから、 *.d.ts にするのは自然です。 いっぽう、 type Bookmark は別のどこかにある *.js の型を与えているわけではないので、 *.ts でよいです。 このように本来 *.ts であるべきものを *.d.ts にしてしまうことには問題があります。代表的な問題として型エラ

Amazon Relational Database Service (Amazon RDS) has new certificate authorities with 40 year and 100 year validity. SSL/TLS certificates enable secure communication between your clients and databases. Administrators can control which certificate their organization uses by setting a default certificate per account with a choice of RSA 2048, RSA4096, and ECC384. When provisioning and modifying a dat

スピーキングで使える頻出パーツフレーズ。覚えておくだけで使えるものばかり100個集めました。留学経験、海外在住経験ゼロでもTOEICスピーキング満点、IELTSスピーキング8.0取ることができました。スピーキングはこういったフレー… https://t.co/xyGOc0MY1p

はじめに 2011年の東日本大震災、これから来ると言われる南海トラフ地震などの大規模な災害や事故に備えるために、災害復旧(DR)が可能なシステムと、その実現手段としてAWSを始めとしたクラウドが長年注目されています。 このDRに関連して、近年「レジリエンス」という言葉が注目を集めるようになりました。 レジリエンスとは、回復力、復元力、弾力などの意味を持つ英単語。IT分野では、情報システムがシステム障害や災害、サイバー攻撃などの問題に直面したとき、迅速に被害からの回復を図り正常な状態に復旧・復元する能力（の大きさ）をこのように呼ぶ。 https://e-words.jp/w/%E3%83%AC%E3%82%B8%E3%83%AA%E3%82%A8%E3%83%B3%E3%82%B9.html AWSでは、2019年8月に大規模障害が発生したことがあり、この時もAZ障害が起きた時に取り得る対策

10 月頭に Linux の [netdev メーリングリスト](https://lore.kernel.org/netdev/)に以下のメールが届きました。 - [netdev development stats for 6.1?](https://lore.kernel.org/netdev/20221004212721.069dd189@kernel.org/) 送信者は Jakub Kicinski で Networking subsystem のメンテナの一人です。元々 netdev は David S. Miller (DaveM) が一人でメンテナンスしており、 Jakub は [DaveM の次の世代のメンテナ](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bda

2022年11月30日03:24（東京）に、AdGuard DNSに深刻な障害が発生し、マイアミ、ニューヨーク、ロンドンの3ヶ所のサーバーが影響を受けました。 障害発生中、これら3つの拠点に接続されているすべてのお客様のインターネットが事実上遮断されました。 これは、AdGuard DNSの全顧客の約20％、すなわち1000万人以上の方がインターネットに問題を抱えたことになります。 影響を受けた方に、このような事態になったことを心からお詫び申し上げます。 今後このような問題が発生しないよう対策を講じる所存です。 何が起きたのか 小さなミスがいくつも重なり、問題発生に至りました。 これらのミスは、それぞれ単独なら致命的ではなく、障害を引き起こすものではありませんでした。 しかし、残念なことに、これらのミスが重なったことこそが、より大きなトラブルの原因となりました。 最初のミスは、11月28日

※この記事は 開発生産性 Advent Calendar 2022 カレンダー2 の20日目の記事です。 前回記事の16日目は nakayamaatsushiさんの 『Findy Team+ Award 受賞の裏側~開発生産性向上の取り組みを振り返る~』でした。計測した開発指標をどのように開発生産性向上に結び付けているのか、具体的なアクション事例が紹介されており非常に参考になりました！ この記事の内容 カナリアリリースを導入しました やってみての感想 うまくいったこと デプロイ頻度が上がる 本番で発覚するバグのユーザー影響を抑えられる 試しやすくなる 期待通りじゃなかったこと 開発リードタイムが短縮される⇒それほどでもない 機能開発のスループットがあがる⇒べつに上がらない マージが分散することで、衝突が起こりづらくなる⇒ならない 本番環境での不具合は発生しなくなる⇒そうとはいいきれない わ