認証・権限
業務上必要な人だけが、必要な情報へアクセスできるよう設計。
最小権限 / アカウント管理SECURITY / ENGINEERING × GOVERNANCE
ASSUME BREACH. TEST. DETECT. IMPROVE.
守るだけではない。
攻撃される前提で、
試して、直す。
情報セキュリティは、ルールを書いて終わるものではありません。
人・権限・ネットワーク・アプリケーション・設定・監視・復旧を、エンジニアリングと運用の両側から継続的に見直します。
「入られない」だけを目指さない。
異常に気づく。広げない。戻せる。
そして、次はもっと強くする。
SECURITY OPERATIONS / OVERVIEWACTIVE
> posture.check(identity, network, app, config) → OK
> vulnerability.scan() → CONTINUOUS
> attack_simulation(PT, BAS, RedTeam) → AUTHORIZED
> decoy.observe() → MONITORING
> config.baseline() → CONTROLLED
> incident.response() → READY
PREVENT権限・設定・更新
不要な入口を減らす。
TEST脆弱性・侵入テスト
攻撃者の視点で弱点を見る。
DETECT監視・デコイ
不審な動きを早く見つける。
RECOVER対応・復旧
影響を止め、戻し、学ぶ。
DEFENSE IN DEPTHNO SENSITIVE TOPOLOGY PUBLISHED
01 / SECURITY PRINCIPLE
セキュリティは、
技術部門だけの仕事ではない。
本気モードは、EC、Web制作、ふるさと納税、観光、システム開発など、異なる種類のデータと業務を扱っています。守る対象も、顧客情報、業務データ、アカウント、ソースコード、システム設定、製造・運用情報など多岐にわたります。
そのため、「強いパスワードにする」「ファイアウォールを入れる」だけでは足りません。人、プロセス、技術を組み合わせ、入口から復旧まで多層で考えます。
さらにTIFGのエンジニアリング機能を持つ会社として、方針や教育だけでなく、検証環境でのテスト、脆弱性確認、セキュアな設定管理、監視・改善までを技術側でも実施します。
方針で守る。技術で試す。
運用で強くする。
02 / DEFENSE IN DEPTH
一つの防御に、
全部を賭けない。
多層防御の考え方で、入口・権限・端末・ネットワーク・アプリ・データ・運用を重ねます。
端末・利用環境
業務端末、更新、利用ルール、持出し等を含めた利用環境を管理。
端末リスクを入口にしないネットワーク
接続、通信、セグメント、公開範囲を管理し、不要な経路を減らす。
つながる範囲を設計するアプリ・コード
開発・変更・レビュー・テストを通じ、実装上の弱点を減らす。
作る段階から守る情報・データ
顧客情報・業務データ等を分類し、取り扱いとアクセスを制御。
守る対象を先に知る監視・対応
異常、変更、障害を見て、発見後の対応・復旧まで準備。
事故ゼロだけを前提にしない03 / ATTACK SIMULATION
自分たちで、
攻撃してみる。
本当に守れているかは、攻撃者の視点で試さないと分かりません。許可された環境・範囲で疑似攻撃を行い、「侵入できるか」「検知できるか」「対応できるか」を確認します。
ATTACK
SIMULATION
防御製品や設定が存在することと、実際に攻撃を止められることは別です。セキュリティ対策の“存在”ではなく、“効いているか”を検証します。
攻撃を模擬する。検知する。封じ込める。
そして、設定と運用へ戻す。
SECURITY TEST MATRIXAUTHORIZED / CONTROLLED / REVIEWED
ペネトレーションテスト
許可された対象に対し、実際の攻撃に近い観点で侵入経路を検証します。
Can it be exploited?BAS
疑似攻撃シナリオを使って、防御・検知・制御が意図通り機能するか継続的に確認します。
Does the defense actually work?Red Teaming
攻撃者を模擬し、単一の脆弱性ではなく、防御・検知・対応全体を演習します。
Can the organization detect and respond?Deception Security
通常は触られないおとりを置き、不審な接触を早期検知のシグナルとして使います。
Can suspicious behavior be detected early?01 / PLAN範囲と目的を決める
対象・影響・許可条件を事前定義。
02 / SIMULATE疑似攻撃を実施
侵入・横展開等を安全な範囲で検証。
03 / DETECT検知できるか確認
アラート・ログ・監視が機能するか。
04 / RESPOND止められるか確認
判断・封じ込め・連携まで確認。
05 / IMPROVE設定と運用へ戻す
見つかった課題をSecCM・開発へ反映。
このページでは、テスト対象・実施頻度・具体的な攻撃シナリオ・検知条件・内部構成・利用ツール等は公開していません。攻撃シミュレーションは、明示的な許可・対象範囲・影響管理のもとで実施する前提です。
04 / SECURITY ENGINEERING
エンジニアが、
自分たちの防御を試す。
「設定したから安全」とは考えません。許可された範囲・環境で、攻撃者の視点を取り入れたテストを行い、見つかった弱点を修正します。
脆弱性診断
既知の弱点、古いコンポーネント、設定上の問題などを確認し、修正優先度を整理します。
「既知の穴が残っていないか」を継続的に確認。VULNERABILITY ASSESSMENTペネトレーションテスト
許可された対象に対し、実際の攻撃者に近い視点で防御を回避できないか検証します。
「本当に侵入につながるのか」を攻撃経路として確認。PENETRATION TESTINGRed Team / Blue Team
攻撃側のRed Teamと、防御・検知側のBlue Teamという考え方で、技術対策だけでなく検知・判断・対応まで確認します。
防御装置があるかではなく、「攻撃を止められるか・気づけるか」。ADVERSARY EMULATION開発時のセキュリティテスト
コードレビュー、依存関係、認証・権限、入力値、秘密情報など、開発工程の中でも安全性を確認します。
リリース後に守るだけでなく、作る段階で弱点を減らす。SECURE SDLC言葉を整理すると
脆弱性診断
弱点を広く探す
既知の脆弱性・設定ミス・更新漏れなどの発見が中心。
ペネトレーションテスト
弱点が実際に攻撃へつながるか試す
権限を持ったテストとして、実攻撃に近い経路を検証。
Red Team
攻撃者を模擬し、防御全体を試す
技術だけでなく検知・連携・対応まで含む演習。
BAS
Breach and Attack Simulation
疑似攻撃を使い、防御・検知・制御が意図通り動作するかを継続的に確認する考え方。
Blue Team
守る・検知する・対応する側
ログ・監視・封じ込め・改善を担う。
05 / DECEPTION & DETECTION
「わざと置くトラップ」は、
ハニーポットという。
通常業務では触られる必要のない“おとり”を置き、アクセスや使用を異常のシグナルとして検知する考え方です。
01 / DECOYおとりを配置
通常業務に影響しない範囲で設計。
02 / TOUCH不審な接触
通常利用では起きにくい挙動。
03 / ALERTシグナル化
監視・通知につなげる。
04 / ANALYZE状況確認
影響範囲・原因を確認。
05 / RESPOND封じ込め・改善
本番資産への影響を防ぐ。
※公開ページでは、具体的なおとりの場所・形式・検知条件・監視対象等は公開しません。セキュリティ対策そのものが攻撃の手掛かりにならない範囲で説明しています。
06 / SECURITY CONFIGURATION MANAGEMENT
コンフィグは、
「触った人の記憶」にしない。
サーバー・クラウド・ネットワーク等の設定は、基準を決め、変更を管理し、意図しない差分を見つけられる状態にします。
BASELINE
セキュアな基準設定
「正しい状態」を先に決める。
CHANGE
変更管理
誰が・何を・なぜ変えたかを管理。
VERSION
バージョン・履歴
設定やコードの変更を追える状態へ。
DRIFT
構成ドリフト確認
意図せず基準からずれた設定を見つける。
REVIEW
定期レビュー
権限・公開範囲・不要設定を見直す。
ROLLBACK
戻せる変更
問題発生時に安全な状態へ戻せるよう設計。
07 / SECURE DEVELOPMENT LIFECYCLE
リリース直前に、
初めてセキュリティを考えない。
要件、設計、実装、レビュー、テスト、リリース、運用まで、開発ライフサイクルの中へセキュリティを入れます。
REQUIRE
扱うデータ・権限・リスクを定義。
DESIGN
認証・権限・通信・保存を設計。
BUILD
秘密情報や入力処理に注意して実装。
REVIEW
コード・設定・依存関係を確認。
TEST
脆弱性・攻撃視点を含め検証。
DEPLOY
変更・権限・設定を管理して反映。
OPERATE
監視・更新・インシデントから改善。
「セキュリティ担当が最後にチェック」から、
「全工程で安全をつくる」へ。
「全工程で安全をつくる」へ。
TIFGの開発フローとセキュリティを分離せず、業務要件・設計・開発・運用の中で判断します。
08 / SECURITY PEOPLE
ルールだけでなく、
専門を持つ人が見る。
東欧エンジニアを含むTIFGチームには、開発だけでなくセキュリティ・ネットワーク領域を専門とするメンバーもいます。
SECURITY & NETWORK SPECIALIST
オクサナ
ロシア出身 / セキュリティ・ネットワーク専門
アプリケーションだけではなく、ネットワークやインフラの視点からも安全性を考える。TIFGでは、ローカルエンジニア・フルスタック・バックエンド・セキュリティの専門性を組み合わせます。
NETWORK通信・接続の設計
SECURITY防御・検知の観点
CONFIG設定・構成の確認
REVIEWエンジニア同士のレビュー
具体的なネットワーク構成、利用製品、IP、ルール、検知条件、内部の運用手順など、攻撃の手掛かりとなる詳細情報は公開していません。
09 / ISMS & GOVERNANCE
エンジニアリングと、
マネジメントの両輪。
技術だけでなく、組織として情報を守る仕組みも必要です。制作部門ではISO/IEC 27001認証を取得しています。
POLICY
方針・ルール
情報の取り扱い、権限、運用を明文化。
PEOPLE
教育・意識
人によるリスクを技術だけに任せない。
ACCESS
アクセス管理
誰が何へアクセスできるかを管理。
SUPPLIER
委託・外部サービス
外部を利用する際もリスクを考慮。
INCIDENT
インシデント管理
発生時の共有・判断・対応を準備。
IMPROVE
継続的改善
一度決めたルールを固定化せず見直す。
10 / BASIC POLICY
情報セキュリティ
基本方針
技術と運用のすべての土台になる、当社の情報セキュリティの基本方針です。
株式会社本気モードについて、第一にお客様はもとより、当社の製品に関わる全ての人々の満足を得る事を目標とし、信頼・安心される会社を目指す。
行動指針
- 情報資産の機密性、完全性、可用性を確実に保護するために組織的、技術的に適切な対策を講じ、変化する情報技術や新たな脅威に対応する。
- 全社員に情報セキュリティ教育の実施と方針の周知徹底をはかり、意識の高揚・維持に務める。
- マネジメントシステム及び、情報セキュリティに関する目的を設定し、定期的にレビューし、継続的に改善を実施し、維持する。
- マネジメントシステムを実行・維持・改善して行くために管理責任者に責任と権限を委譲する。
2021 年 4 月 22 日 株式会社本気モード 代表取締役社長 樋口憲一
11 / INCIDENT RESPONSE
事故が起きたときの強さも、
セキュリティ。
完全に防ぎ切ることだけを前提にせず、異常の発見から封じ込め、復旧、改善までを一連の運用として考えます。
検知
異常・アラート・報告から事象を把握。
早く気づく。評価
何が起きたか、影響範囲と優先度を確認。
正しく判断する。封じ込め
被害・影響が広がらないよう必要な措置を取る。
広げない。復旧
安全な状態を確認し、サービス・業務を戻す。
戻せる。改善
原因・対応・検知方法を振り返り、次の対策へ反映。
次は強くする。
SECURITY CONTACT
セキュリティ上の懸念に
セキュリティ上の懸念に
お気づきの場合。
当社Webサイト・サービス等に関するセキュリティ上の懸念や、当社に関係すると思われる不審な事象にお気づきの場合は、公開された問い合わせ窓口からご連絡ください。
安全上の理由から、公開環境に対する無断の侵入テスト、過度なスキャン、データ取得、サービス妨害等は行わず、まずご連絡ください。