セキュリティモデルと責任範囲

セキュリティは専有物理 Mac から始まり、明確な運用範囲によって支えられます

BookaMac では、共有ホスト上で分割した仮想マシンではなく、ご注文ごとに専有物理 Mac mini を 1 台割り当てます。物理的に分離することで他の利用者と計算リソースを共有する範囲を抑えられますが、認証情報、コード、証明書、依存関係、リモートセッションは、利用者が適切なエンジニアリング規範に沿って管理する必要があります。

本ページでは、当社が担う範囲、お客様が管理する範囲、異常発生時に双方が検証可能な情報を提供する方法を説明します。

1 件の注文 専有物理マシン 1 台に対応
仮想マシンではありません OS インスタンスを共有しません
責任を追跡可能 プラットフォームと利用者の境界をそれぞれ明示
分離は管理不要を意味しません

専有物理マシンで解決できること、なお管理が必要なこと

セキュリティ機能を評価する際は、ハードウェア分離、ID 管理、ワークロード管理、データガバナンスを分けて考える必要があります。異なるレイヤーの責任を「専有」という一言で置き換えることはできません。

注文単位の物理分離

有効な各注文には専有物理 Mac mini 1 台が対応します。お客様のワークロードは、他の注文と同じ OS インスタンス、メモリ領域、ローカルディスクのファイルシステムを共有しません。これは、複数のテナントがホストの分離機構に共同で依存する共有コンピューティング環境とは異なります。

  • 物理プロセッサ、メモリ、デバイスのローカルストレージは注文ごとに専有
  • 稼働中の同一デバイスを複数の注文に同時割り当てしません
  • ディレクトリ構成と引き渡し情報は注文内容で確認できます

分離によって脆弱な認証情報が自動的に修正されるわけではありません

管理者 ID の共有、秘密鍵の使い回し、リポジトリへの認証情報の保存、リモートセッションの長時間維持は、物理分離のメリットを損ないます。ID と権限は利用者が主体的に最小化してください。

分離はバックアップではありません

専有ローカルディスクがあるからといって、別のコピーが存在するわけではありません。リポジトリ、ビルド成果物、モデルファイル、メディア素材は、復旧目標に応じて利用者が管理する場所へ保存し、注文終了前に検証してください。

範囲を判断する方法: リスクが他のテナントとの計算リソース共有に起因する場合、専有物理マシンによってリスク範囲を縮小できます。一方、弱いパスワード、誤削除、悪意のある依存関係、過剰な権限、未バックアップのデータに起因するリスクは、ワークフロー内で個別に管理する必要があります。
アクセス制御

まず ID を分け、タスクに必要な最小権限まで絞り込みます

安全なリモート Mac に、複数人が長期間共有する管理者入口を 1 つだけ設けるべきではありません。担当者、自動化タスク、一時的な調査には、それぞれ異なる ID とライフサイクルの認証情報を使用してください。

01 / ID

操作者ごとに個別の認証情報を使用

ログインが必要な担当者には識別可能なローカル ID を作成し、複数人で管理者アカウントを継続的に共有しないでください。メンバーがプロジェクトを離れたり担当が変わったりした場合も、全員の認証情報を交換せずに個別にアクセスを無効化できます。

  • 担当者用 ID と自動化用 ID を分離
  • 一時的な調査権限には明確な終了時点を設定
  • チャット履歴で完全な認証情報を共有しない
02 / 鍵

ノードごとに固有の SSH 鍵を生成

同じ秘密鍵を複数のプロジェクトやデバイスにコピーしないでください。チーム、環境、ノードごとに鍵を分け、秘密鍵にはローカル保護を設定することを推奨します。鍵の漏えいが疑われる場合は、対応する公開鍵を直ちに削除して再発行してください。

  • 秘密鍵は管理下の端末にのみ保存
  • 公開鍵を変更したらログイン検証を 1 回実行
  • ローテーション記録に操作者と完了時刻を記載
03 / 権限

継続的な管理者権限をデフォルトで付与しない

日常的なコード取得、ビルド実行、ログ確認に、常時管理者 ID は通常必要ありません。システムレベルのツールをインストールするときや保護された設定を変更するときだけ一時的に権限を昇格し、操作後に変更範囲を確認してください。

  • ビルドサービスは必要なディレクトリにのみアクセス
  • 自動化スクリプトに長期間有効な高権限認証情報を保存しない
  • 環境変更をチームの運用記録に残す
リモートアクセス保護

初回接続、日常のセッション、異常確認を定型化

SSH と GUI 接続は役割が異なりますが、対象ノードの確認、認証情報の保護、セッションの明示的な終了、十分なトラブルシューティング情報の保持が必要です。

SSH ROUTE

コマンドライン接続の確認

  1. 接続先を確認

    注文の引き渡し情報でアドレス、ポート、ユーザー名を確認し、出所不明の転送アドレスは使用しないでください。

  2. ホストフィンガープリントを検証

    初回接続時またはフィンガープリントが変わった場合は、ログインを中止して引き渡し情報を再確認してください。接続を続けるために警告をそのまま無視しないでください。

  3. 一時的な認証情報を置き換え

    初回アクセス後に自分の公開鍵を登録し、新しいセッションが利用できることを確認してから、不要になった一時的な入口を削除してください。

  4. 異常記録を確認

    見慣れない送信元、通常と異なる時間帯、連続した失敗試行を確認してください。不審な挙動を見つけたら、まずアクセスを制限し、匿名化した証拠を保存します。

GRAPHICAL SESSION

GUI セッション管理

  1. 認証情報をスクリプトやリポジトリに保存しない

    GUI アクセスの認証情報は、管理下にあるローカルの認証情報管理ツールに保存し、プロジェクト設定、ビルドログ、共有ドキュメントには記載しないでください。

  2. 画面共有前に機密情報を整理

    リモートで共同作業を行う前に、鍵、証明書、支払い情報、内部アドレスを含むウィンドウを閉じ、問題の解決に必要な範囲だけを表示してください。

  3. 作業後は明示的にログアウト

    アプリのウィンドウを閉じただけではリモートセッションは終了しません。作業後にセッションを終了し、一時的な転送やバックグラウンドツールが残っていないことを確認してください。

  4. 接続異常はまず資料に沿って確認

    接続ガイドに従ってローカルネットワーク、対象アドレス、ポート、フィンガープリント、認証情報の状態を確認し、その後、匿名化したログをコンソールから送信してください。

初回接続の手順を見る
データライフサイクル

取り込み前の分類から、注文終了前の検証可能なデータ移行まで

データセキュリティは注文の有効期限になってから始めるものではありません。ノードにデータを入れる前に、データ種別、復旧先、クリーンアップ担当者を決めておくことを推奨します。

A

取り込み前

タスクに必要なリポジトリ、依存関係、素材、モデルファイルだけを同期してください。鍵、証明書、本番データにはより厳格なアクセス範囲を設定し、個人のダウンロードフォルダ全体をノードにコピーしないでください。

検証結果:ノード内のデータ範囲がタスク一覧と一致。
B

利用期間中

作業内容のディレクトリ権限、バージョン管理、バックアップ、コンプライアンス管理は利用者が担当します。重要な成果物は利用者が管理するストレージへ同期し、デバイスのローカルディスクを唯一のコピーにしないでください。

検証結果:重要なコードと成果物に独立した復旧可能なコピーが存在。
C

期限前

リポジトリ、ビルド成果物、ログ、必要な設定を移行し、ファイル数、チェックサム、またはリポジトリの状態を検証してください。その後、不要になった鍵、認証情報、証明書、一時ファイルを削除します。

検証結果:新しい場所から読み取り可能で、ノード内の機密アクセス情報を無効化済み。
D

注文終了後

ノードはサービス処理に移行し、元の注文にはアクセスを提供しなくなります。プラットフォームは、引き渡し、セキュリティ、サービス運用に必要な原則に基づいてデバイスの状態を処理します。注文終了後のデバイスをデータ保管先として扱わないでください。

検証結果:業務復旧が終了済みの注文に依存していない。

利用終了時の最低条件:先にデータを移行して検証し、その後ローカルコピーを削除します。先にアクセス情報を無効化し、その後担当者の操作記録を終了します。「コピー済み」を「復旧検証済み」と混同しないでください。

ネットワークとログ

運用記録とユーザーの作業内容を分けて扱う

サポートやセキュリティ調査には限定的な接続記録・サービス記録が必要ですが、これらはユーザーのコード、ドキュメント、ビルド内容を通常確認するものではありません。

運用ログとユーザー作業内容の取り扱い範囲
情報カテゴリ 代表的な内容 利用目的 ユーザーが行うこと
接続記録 接続時刻、送信元情報、対象サービス、結果ステータス 接続トラブルの調査、異常な試行の特定、サービス運用の維持 問い合わせ時に正確な時刻を提示し、送信元アドレスは必要に応じて匿名化
注文・デバイスの状態 注文 ID、構成、地域、引き渡し状況、基盤の稼働状態 引き渡し、更新、障害特定、セキュリティインシデントの範囲確認 必要な注文 ID のみ提示し、完全なアクセス認証情報は送信しない
サポートでの通信 問題の説明、匿名化ログ、再現手順、対応記録 質問への回答、対応状況の追跡、重複調査の防止 秘密鍵、アクセストークン、証明書の内容、無関係な個人情報を削除
ユーザーの作業内容 コード、素材、モデル、プロジェクト文書、ビルド成果物 ユーザー自身のワークフローで管理し、通常の運用ログには含めない 権限、バックアップ、コンプライアンス範囲、利用終了時のクリーンアップ規則を自分で設定
調査資料を送る前に: コマンド、エラーコード、時刻、必要なコンテキストを残し、秘密鍵、完全な認証情報、証明書本文、アクセストークン、業務データ、無関係な個人情報を削除してください。
支払いに関する範囲

支払い方法を限定し、注文はすべて米ドルで決済

BookaMac は USDT-TRC20 と Visa / Mastercard / Amex(Stripe 経由)のみを受け付け、すべて米ドル(USD)で決済します。実際に利用できるゲートウェイは、チェックアウト時に表示される内容をご確認ください。

決済処理では、取引の完了、支払い状況の確認、請求に関する問題への対応、必要なセキュリティ要件を満たすために必要な情報のみを収集します。支払い認証情報と、ユーザーノード内のコード、ファイル、ビルド内容は別の処理範囲に属します。

USDT-TRC20

オンチェーン決済

支払い前に注文金額、ネットワーク、送金先情報を確認してください。取引 ID は状態確認に使用できますが、ノードのアクセス認証情報と一緒に送信しないでください。

CARD / STRIPE

カード決済

Visa、Mastercard、Amex に対応しています。支払い手順では各決済フローに必要な取引情報を処理し、注文状況はコンソールの表示を基準とします。

セキュリティインシデント対応

断定を急がず、証拠に基づいて 5 段階で対応

異常な接続、認証情報の漏えい、デバイス状態の変化、不審な行動が発生した場合は、まず影響範囲を確認します。検証されていない情報を絶対的な安全性の結論として扱いません。

  1. 01

    検知

    異常が発生した時刻、注文 ID、地域、確認した行動、最小限の再現条件を記録し、匿名化した元ログを保存します。

  2. 02

    影響を限定

    リスクに応じて鍵を無効化し、異常なセッションを終了し、ネットワークアクセスを制限するか、関連する自動化を停止して、露出範囲の拡大を防ぎます。

  3. 03

    調査

    時系列に沿って接続記録、設定変更、ユーザー操作、サービス状態を照合し、認証情報の問題、ワークロードの問題、プラットフォームの問題を切り分けます。

  4. 04

    修復

    影響を受けた認証情報を交換し、設定を修正し、不審な永続化内容を削除したうえで、新しい接続またはビルドタスクにより修復結果を検証します。

  5. 05

    通知

    事実を確認した後、影響範囲に応じて必要な説明、実施した対策、ユーザーが次に行う操作を案内し、未確認の推測が広がらないようにします。

責任ある開示

脆弱性を報告する際は、再確認できる証拠を示し、テスト範囲を管理してください

セキュリティ調査と問題報告は、影響を抑えることを前提とします。アクセス範囲を広げず、無関係なデータを取得せず、修正前の問題を公開しないでください。

調査に進められる報告に含める内容

影響対象

対象となるウェブページ、注文フロー、接続方法、デバイス機能、および確認できた影響範囲。

再現手順

初期条件から観察結果までの最短手順。必要なリクエスト順序、入力条件、期待される動作を含めてください。

証拠と時刻

匿名化したスクリーンショット、エラー情報、関連する時刻、環境の説明を提示し、秘密鍵や第三者データは添付しないでください。

連絡先

追加の質問を受け取れるメールアドレス、タイムゾーン、連絡可能な時間帯を記載し、検証情報を補足できるようにしてください。

テスト時に禁止される行為

  • 自分に属さないデータへのアクセス、ダウンロード、変更、削除
  • 他のユーザーの認証情報の取得、または無関係な注文への範囲拡大
  • ノード、ネットワーク、支払い、サポートの正常な運用を妨害
  • 欺瞞、なりすまし、誘導による担当者権限の取得
  • 修正と連絡が完了する前に、悪用可能な詳細を公開
範囲をすばやく確認

よくあるセキュリティに関する質問

以下の回答は、次に行う操作をすばやく判断するためのものです。特定の注文については、注文 ID、地域、時刻、匿名化したログを添えてください。

専有物理マシンならアクセス制御は不要ですか?

いいえ。専有物理マシンは他のテナントと計算リソースを共有する範囲を抑えますが、弱いパスワード、秘密鍵の漏えい、過剰な権限、悪意のある依存関係、誤操作を防ぐものではありません。各操作者は個別の ID を使用し、タスクに必要な最小権限を付与してください。

SSH 鍵やリモート接続の認証情報が漏えいした疑いがある場合、最初に何をすべきですか?

まず影響を限定します。該当する公開鍵を無効化または認証情報を交換し、不審なセッションを終了して関連する自動化の使用を停止してください。その後、異常の時刻、送信元、注文 ID、実施した対応を記録し、匿名化した情報をコンソールのチケットから送信します。

ログを提出する際、必ず削除すべき内容は何ですか?

秘密鍵、完全なパスワード、アクセストークン、証明書本文、業務データ、無関係な個人情報を必ず削除してください。コマンド、エラーコード、必要なパス、正確な時刻、問題を説明できる最小限のコンテキストは残します。

注文終了前に最も重要なデータ操作は何ですか?

コード、ビルド成果物、ログ、必要な設定を利用者が管理する場所へ移行し、読み取り、チェックサム、または復旧を検証してください。その後、ノード内の鍵、認証情報、証明書を無効化してから、注文関連の操作を終了します。

次のステップ

セキュリティ範囲を確認してから、ワークフローに合う物理 Mac を選ぶ

販売中の 2 構成、利用期間別の料金、4 地域の選択肢を確認できます。既存の注文については、コンソールにログインしてチケットを提出してください。