はじめに Linuxの良い所の一つにsuやsudoと言った特権管理の仕組みがあります。普段は通常アカウントで入って、例えばインストールなどの特権作業が必要な時だけsu/sudoで一時的な権限昇格が可能ですし、/etc/pam.dで誰がどのユーザにスイッチ出来るかなどは細かく制御できます。 一方で、クラウドの権限管理は悩みの種で、誤操作が怖いので普段はRead Onlyの権限にしておきたいのですが、手軽に権限を昇格する方法がありません。なので、別の管理者ユーザを作って、そちらでログインしなおしたり、それを半自動化するCyberArkやBeyondTrustといったPAM系ソリューション、あるいは最近流行りのCIEM(PAM機能を持つもの)を導入する必要がありました。 Azureでは結構以前からPIM(Privileged Identity Management)がネイティブで組込まれており非

今回答えを出したい問いはこちら！！ インデックスはどのような仕組みを以て、何を実現したいものなのか それを踏まえたとき、インデックスはどういう場合になぜ貼る方が良いのか。また、どういう場合になぜ貼らない方が良いのか 大体分かっているよって人はサヨナラって感じのおさらい記事だぜ！！！！それじゃいってみよー🎉 あと、おれは今回MySQLにしぼっていくぜ👶 ってわけでOracleとかに興味があるやつは引き返しな！ indexの概要 公式の見解としては「where句を使ったselectクエリの実行速度を向上させるために実装されている、各行へのポインターのような振る舞いをする仕組み」って感じ👶 The best way to improve the performance of SELECT operations is to create indexes on one or more of t

Intro CSRF という古の攻撃がある。この攻撃を「古(いにしえ)」のものにすることができたプラットフォームの進化の背景を、「Cookie が SameSite Lax by Default になったからだ」という解説を見ることがある。 確かに、現実的にそれによって攻撃の成立は難しくなり、救われているサービスもある。しかし、それはプラットフォームが用意した対策の本質から言うと、解釈が少しずれていると言えるだろう。 今回は、「CSRF がどうして成立していたのか」を振り返ることで、本当にプラットフォームに足りていなかったものと、それを補っていった経緯、本当にすべき対策は何であるかを解説していく。 結果として見えてくるのは、今サービスを実装する上での「ベース」(not ベスト)となるプラクティスだと筆者は考えている。 CSRF 成立の条件 例えば、攻撃者が用意した attack.examp

エンジニアの岡村です。 自分はサーバーがメインではなく、あまり業務でガッツリ触るわけでもないのですが、最近それなりに活用するようになってきました。しかし、ネット上の日本語情報を読んでいるだけではこれの書き方が正しいのかよく分からない、と悩むことが結構あったため、色々情報を漁ってみました。 この記事は、特に自分が気になった部分の調べた結果を記事に纏めてみたものです。対象読者はdocker-composeを雰囲気でupやdownは叩けるけどComposeファイルの書き方がよく分からんとなってる人です。 Docker Composeの概要とcompose.yaml、Compose Specの関係 compose.yamlの書き方は Compose Specに準拠すればOK Compose Specの場所 推奨のファイル名はcompose.yaml compose.yaml内にバージョンを記述する

はじめに エンジニアとして就職する前に読んだ「なれる!SE 2週間でわかる?SE入門」の内容があまりにも厳しく、業界に就職するのが怖くなったことを覚えています。本の中に登場する中学生の少女にしか見えない凄腕のSE、室見立華さんのような人物は現実には存在しないでしょうが、実際の業界には彼女のような凄腕エンジニアや年齢不相応な技術力を持つ人間も確かに存在します。 なれる！SE ２週間でわかる？ＳＥ入門 (電撃文庫) 作者:夏海 公司,IxyKADOKAWAAmazon SREの探求『Becoming SRE』の内容紹介 私は「なれる!SE」が好きすぎるあまり、「なれる!SRE」というタイトルのクソみたいな文章を吐き出したこともありましたが、そのクオリティがあまりにも低かったため、外には公開せずに留めておきました。そんな中、SREの探求の原著者であるDavid Blank-Edelman(ott

こんにちは、@hamayanhamayan です。 本稿ではWebセキュリティに対する有用な文書として広く参照されているOWASP Top 10の1つ「インジェクション」について考えていきます。色々なインジェクションを例に挙げながら、どのようにインジェクションが起こるのかという発生原理から、どのようにインジェクションを捉え、より広くインジェクションの考え方を自身のプロダクト開発に適用していくかについて扱っていきます。 SQLインジェクションやコマンドインジェクション、XSSのようなインジェクションに関わる有名な手法について横断的に解説をしながら、インジェクションの概念を説明していきます。初めてインジェクションに触れる方にとっては、インジェクションの実例や基本的な考え方に触れることができ、その全体像を把握する助けになるかと思います。 また、既にいくつかのインジェクション手法を知っている方にと

先週の火曜日、3月12日に始まったPublickeyへのDDoS攻撃は今週日曜日、3月18日日曜日の早朝を最後に収まったようです。この記事執筆時点でPublickeyのサーバは平常に戻っています。 この間、読者や広告を掲載いただいているお客様や代理店様にご不便やご心配をおかけし申し訳ありませんでした。 DoS攻撃とは、大量のトラフィックをWebサーバなどに浴びせることでサーバを応答不能にしてしまう攻撃のことです。 前回の報告「Publickeyが受けたDoS攻撃、これまでの経緯と対策まとめ」の後、さらにいくつか対策を講じましたので、この記事では前回の報告以後の経緯と講じた対策を記したいと思います。 また、前回の報告では「DoS攻撃」と書きましたが、その後Publickeyのサーバをホスティングしているさくらインターネットのサポート担当の方から、今回の攻撃は分散した箇所から攻撃を受けていると

sumirenです。 技術顧問やSREをしています。 背景 2024年現在、OpenTelemetryが盛り上がっており、ベンダへの依存度を下げてテレメトリを収集・送信することがトレンドになってきているように思います。多くの企業様で、OpenTelemetry対応のオブザーバビリティバックエンドを選定されているのではないでしょうか。 一方で、E2E自動テストツールなどもそうですが、デベロッパーツールは画面やUXの情報がパブリックな情報として出回ることが少ないように思います。オブザーバビリティバックエンドの場合、シグナル3種に関してOpenTelemetryベースでもフルに機能が活用できるのかという疑問もあります。 そうしたこともあり、オブザーバビリティバックエンドは実際にトライアルしてみないと選定しづらいです。監視など狭義のオブザーバビリティ外の機能や、OpenTelemetryの範囲外の

総務省は、本日、LINEヤフー株式会社（代表取締役社長 出澤 剛、法人番号 4010401039979、本社 東京都千代田区）に対し、同社における、不正アクセスによる通信の秘密の漏えい事案に関し、通信の秘密の保護及びサイバーセキュリティの確保の徹底を図るとともに、再発防止策等の必要な措置を講じ、その実施状況を報告するよう、文書による行政指導を行いました。 LINEヤフー株式会社（代表取締役社長 出澤 剛。以下「LINEヤフー社」という。）からの報告により、同社及び同社のITインフラの運用に係る業務委託先であるNAVER Cloud社が、それぞれセキュリティに係るメンテナンス業務を委託していた企業においてマルウェア感染が生じたことを契機として、NAVER Cloud社の社内システムが侵害されるとともに、同社を介して、同社とネットワーク接続のあったLINEヤフー社の社内システムに対して不正アク

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

DNSは趣味でやっているだけですし有識者のレビューを経ているわけでもないので誤りを含むかもしれませんが、DNS界隈には優しい人しかいないのできっと丁寧に指摘してくれるはずです。 追記：めちゃくちゃ丁寧にレビューしていただいたので修正いたしました。森下さんほどの方に細かく見ていただいて恐れ多いです...（学生時代に某幅広合宿で森下さんの発表を見てDNSセキュリティに興味を持った） 4万文字を超える大作、おつかれさまです。わかりやすく書けていると思いました。 ざっと読んで、コメントしてみました。ご参考まで。https://t.co/bVj5WeFHQr https://t.co/ku5NOx6ua8— Yasuhiro Morishita (@OrangeMorishita) 2024年2月19日 要約 背景 詳細 DNSSECとは？ DNSSECの可用性 鍵タグの衝突 攻撃内容 SigJam

みなさん、こんちにはmです。 今回は私が1年の期間でマルウェア解析のスキル0から習得するまでに取り組んだ方法をまとめました。 初めに開始時のスキルや1年間でかけたコスト、スケジュールなどを共有します。 開始時のスキルなど 表層解析、動的解析、静的解析の違いもあまり理解していない プログラミングはPythonを学び始めた程度 低レイヤーの知識なし アセンブリの知識なし Windowsアプリケーション開発の経験なし SOCアナリストとしてブルーチームの知識は多少 脆弱性診断の経験も（深くはないが）多少 エンジニア歴7、8ヶ月目くらい ざっくりですが、このようにマルウェア解析に絡んでくる知識はほぼ0でした。 学習にかけたトータルコスト 書籍：約5万円 オンライン教材：12万円 約17万円近く1年間に使いましたが、お金で直接スキルは買えないので必要経費です。 なお、オンライン教材の12万円について

はじめに CSIRT とは CSIRT を立ち上げるモチベーション セキュリティインシデントは避けられない 意思決定者の訓練機会の不足 世界的なインシデントレスポンスの重要性の高まり CSIRT 作りの準備 教科書に学ぶ 他社に学ぶ テックタッチにおける CSIRT の設計 スモールスタートするための責任境界 ちゃんと機能する！ハンドリングマニュアル 窓口の明確化 継続的なスペシャリティの維持 さいごに 参考 はじめに こんにちは。SRE 兼 CSIRT の izzii（𝕏）です。Flatt Security mini CTF #4 に参加して入賞景品のTシャツをゲットできたのが最近のプチ自慢です。 さて本日の記事は、テックタッチにおいて私含む現場のメンバー（izzii, kacchan, ue）が Computer Security Incident Response Team (CS

こんにちは、北海道から freee PSIRT（Product Security Incident Response Team）に参加している yu です。 今年は雪が少ないな〜と思っていたら最近ドカドカ降るようになってきて、1日デスクで集中した後に外に出ようとすると玄関のドアが雪で開かない日もありました。雪国エンジニアの各位、除雪も忘れず頑張っていきましょう！ さて、この記事では前回の記事で bucyou が紹介した開発合宿において、私と同僚の tomoya さんで取り組んだ freee の Attack Surface Management（以下、ASM）について紹介します。 ASM とは ASM、Attack Surface Management という用語はさまざまなところで異なる定義がされており、私自身、この言葉を使うときにはまだ少しだけ違和感があります。 国内では昨年の5月に経

サイバー攻撃を防ぐため、政府は、基幹インフラを担う企業が重要な設備を導入する際に国が事前審査を行う制度の対象に、新たに「港湾運送」の業種を追加することになり、必要な法律の改正案を国会に提出する方針です。 これは29日に開かれた経済安全保障の強化に向けた政府の有識者会議で了承が得られたものです。 経済安全保障推進法では、電気や通信、金融など14の業種を基幹インフラに指定し、重要な設備を導入する際には、サイバー攻撃の防止に向けて国が事前審査を行うとしていて、ことし5月から制度の運用が始まります。 しかし、去年7月には名古屋港のコンテナターミナルでサイバー攻撃によるシステム障害が発生し、一時コンテナの積み降ろしができなくなったことから、こうした事態を防ぐため、新たに「港湾運送」も対象に追加されることになりました。 政府は、早ければ今の通常国会に経済安全保障推進法の改正案を提出する方針で、港湾運送

CSIRT（Computer Security Incident Response Team）▼などのセキュリティーチームは有事に適切に対応する必要がある。その能力を鍛えるには定期的なサイバー演習が欠かせない。 国内CSIRTの集まりである日本コンピュータセキュリティインシデント対応チーム協議会（日本シーサート協議会、NCA）▼は年に1回、内閣サイバーセキュリティセンター（NISC）▼と合同でサイバー演習の「NISC／NCA連携分野横断的演習▼」を開催している。直近の2023年12月7日開催回には、NCAの会員企業・団体から前回比2割増の120チーム（813人）が参加。演習の重要性への意識が高まっていることがうかがえた。 情報流出や脅迫にどう対応するか 今回の演習では、企業・団体ごとに15人までのインシデント対応チームを構成した。うち1人が「サブコントローラー」として演習の司令塔となり、N

1. 始めに こんにちは、morioka12 です。 本稿では、AWS 環境における攻撃者のオフェンシブな視点で Cloud Security の入門として紹介します。 1. 始めに 免責事項 想定読者 2. クラウドにおける脅威 クラウドの重大セキュリティ脅威 11の悪質な脅威 クラウドサービス利用に関連するリスク Top 10 AWS セキュリティ構成ミス Top 10 3. AWS 環境における攻撃者の観点 3.1 AWS 環境の外部からの観点 3.2 AWS 環境の内部からの観点 4. MITRE ATT&CK Framework for Cloud (IaaS) 4.1 初期アクセス (Initial Access) 4.2 実行 (Execution) 4.3 永続化 (Persistence) 4.4 権限昇格 (Privilege Escalation) 4.5 防御回避