「MNTSQ（モンテスキュー）」のTechブログです。
Live Last read · last published · next check
はじめに 1. 取り組みの全体像 2. Security Hub 刷新の道程 3. フロントエンドとバックエンドの体制調査で見えたもの 4. 具体的な改善 5. 対応後処理 6. 今後の展望 はじめに SaaS を提供する事業者にとって、セキュリティ体制の維持・改善は事業の成長に直結するテーマです。弊社でも、顧客からセキュリティ対策の状況について問い合わせや開示を求められる場面は少なくありません。セキュリティへの投資は単なる守りのコストではなく、顧客からの信頼を獲得し、プロダクトの成長を後押しする取り組みでもあると捉えています。 note.mntsq.co.jp 一方で、この取り組みに着手した当初、脆弱性管理の実態を顧客に説明する対外説明資料は十分に整っていませんでした。 本稿は、そこから対外説明資料を積み上げていった、1年あまりの取り組みの記録です。Amazon Inspector…
こんにちは、MNTSQ株式会社セキュリティ推進室の北村です。 セイ・テクノロジーズ株式会社・株式会社K-model共催のオンラインセミナー「実際どうやる？ ISMS取得企業がSCS評価制度に対応するためのセキュリティ運用設計」（2026年5月22日開催）に参加しました。 「SCS評価制度」という名前はここ最近よく耳にするようになりましたが、「ISMSと何が違うの？」「本当に対応が必要なの？」という疑問を持っている方も多いのではないかと思います。このレポートでは、参加を通じて理解したことや気づきをまとめてお伝えします。 なぜセミナーに参加したのか MNTSQは、SaaS型契約管理プラットフォーム「MNTSQ CLM」を提供しています。すでにMNTSQ CLMをご利用いただいているお客様には大手企業も多く、そうした企業のサプライチェーンの一端を担う「受注側」でもあります。…
はじめに セキュリティ推進室の山田です。 MNTSQは2025年10月にオフィスを移転しました。 その際にオフィスネットワークを構築しましたが、Web会議の通信遅延や定期的なネットワークの不調がたびたび発生し、全社的な課題となっていました。 その調査をするには可視化が必要と判断し、SNMPでネットワーク機器のメトリクスを収集してDatadogに集約する構成を作りました。この記事はその取り組みのひとつで、SNMPマネージャーの構築について紹介します。 課題：ネットワークの状態を一元的に把握できない MNTSQのオフィスネットワークはルーター、L3スイッチ、L2スイッチ、APで構成されていますが、複数メーカーの機器が混在しています。各機器にはそれぞれ管理画面が用意されていますが、ネットワークの状態を確認したいときに機器ごとにログインしなければならず、全体像を把握するのに手間がかかる状態でした。…
はじめに 実態調査 課題感 改善 1. Redash 内部 DB から events を吸い出して Athena に載せる 考慮箇所 2. 通知本文に操作内容の要約を載せる 効果 おわりに はじめに 弊社では BI ツールとして Redash を運用しています。操作内容の監査を考える場合、BI ツールという性格上、誰がいつどのデータソースに対して何を実行したかを後から追える状態を保つことは、監査の観点で外せない要件になっています。 これに対し、営業時間外（平日深夜早朝・土日終日）に Redash 上で操作の形跡があれば、その操作者本人に Slack 上で利用目的の回答を促す、という監査運用を敷いてきました。検知した操作を放置せず、必ず本人に説明責任を返す、という運用思想を名前にした格好です。なお、操作者本人まで辿れるのは、Redash へのログインを IAM Identity Center…
はじめに SREの寺島です。 Amazon SQS をタスクキューのブローカーとして使うとき、実行時間の短いジョブと長いジョブが混在していると、処理に時間のかかるタスクが途中で再配信されてしまう問題に当たります。可視性タイムアウト(Visibility Timeout)を長くすれば防げますが、長くするほど障害時の復旧が遅くなるというトレードオフがあります。 これを解決するのが、可視性タイムアウトを短く設定し、処理中にハートビートで動的に延長する方法です。本記事では Celery を使った実装例を紹介します。 はじめに SQS + Worker の非同期処理の構成 可視性タイムアウト設計の難しさ 解決策 具体的な動作 実装サンプル ReceiptHandle / Queue URL の取得 ハートビート本体 タスク側 注意点 動作確認 通常時：長時間タスクでも再配信されない…
藤原です。 パブリッククラウドのコストコントロール、どこから手を付けていますか？ 本エントリでは、2026年上期に取り組んだAWSコストコントロール施策を題材に、 AIを壁打ち相手として使いながら、施策の棚卸し → 想定削減効果の見積もり → 優先度づけ → 実施判断を進めた 事例を解説します。AIと人間の役割分担について、ひとつの例として捉えてもらえるとありがたいです。 コスト削減の進め方とAI コスト削減の打ち手そのものは、実はそれほど目新しいものではありません。教科書的な施策は山ほどあります。 とくに難しかったり大変なのは施策の実行ではなく、その前段階です。進め方をざっと大枠で分けると 棚卸し 自分たちの環境で効きそうな施策を漏れなく洗い出す 見積もり それぞれが「いくら効くのか」を、自分たちの請求データに基づいて試算する 優先度づけ…
藤原です。 みなさん、システムコストの管理、どうしていますか？ システムコストがどの程度発生しているのか、どんな機能から発生しているのか、特定の機能が利用された際にどの程度のコストがかかっているかを気にしたことはありませんか。 本エントリでは、Datadog Cloud Cost Managementを使ったマルチクラウド環境におけるコスト管理ダッシュボードの作成事例および、コスト計算を実現する方法について事例ベースで解説します。 複数クラウドのコスト管理 コスト管理を複数のクラウドサービスにまたがって行うには、多くの課題が生じがちです。 おそらくは以下のいずれかで管理している方が多いかと思います。 毎月の初めに個別クラウドの請求書をダウンロードしてスプレッドシートに転記の上、報告資料を準備…
はじめに 既存構成 課題感 設計 CloudWatch Logs ではなく S3 に倒す クラスタ単位で S3 prefix を切る 実装 ECS タスクロールに付与する IAM ポリシー ECS クラスタの executeCommandConfiguration おわりに はじめに Amazon Linux 2 (以下 AL2) の EOL (2026 年 6 月 30 日) が近付いてくる昨今、皆様いかがお過ごしでしょうか。 弊社では SSH 踏み台として使う EC2 インスタンスを AL2 ベースで用意し、運用作業の起点として長年取り扱ってきました。運用者はここを経由して ECS タスクや各種マネージドサービスへアクセスしてきた経緯があり、単純な SSH 踏み台ではなく、運用機能を集約した実行基盤として機能してきた格好です。 前述の通り ECS 最適化 AL2 AMI の EOL…
はじめに SREの寺島です。 MNTSQでは継続的なコスト最適化を進めており、SREチームでもこれまでいくつかの削減施策を実施してきました。本記事では、その中からNAT Gatewayのデータ処理料金の削減に向けた取り組みを紹介します。 結果として、NAT Gatewayのデータ処理料金を約70%削減することに成功しました。今回は、コスト増の原因特定から、具体的な対応、そして効果測定にいたるまでの一連の流れをお届けします。 はじめに まずは Cost Explorer でコストの把握をする NAT Gateway の通信内容を調査する VPC Flow Logs テーブル定義 集計クエリ Route 53 Resolver Query Logs テーブル定義 IP からホスト名を引くクエリ 集計結果 ECR Public が CloudFront 経由で配信されていることを curl…
はじめに 「監視モニタリングのIaCとか机上の空論だろ。労力とリターンが見合わんわ」 …と思っていた時期が私にもありました（慣用句） 前回の記事 でも少し触れましたが、 AIエージェントの登場によってDatadog × Terraformのような監視モニタリングのIaCの実践が劇的に楽になり 、気づけば手動でポチポチとモニタリングの設定をする運用の方が限りなく非効率になってしまいました。 AIエージェントをどう利用するかという部分は、まだまだ過渡期であり皆さま試行錯誤中ではあると思いますが、 弊社SREチームではAIエージェントを活用し 、 モニタリング対象の飛躍的な拡充 、 モニタリングコード品質の大幅な改善 、 運用負荷の劇的な軽減 を実現できました。そこで、どのような取り組みを行い、これを実現したかを紹介したいと思います。 ※ 本記事で扱うのはDatadog × Terraform…
