10. セキュリティ

セキュリティは後付けの機能ではありません。Build.ioの運用そのものに組み込まれています。コードを実行するインフラから、チームがプラットフォームにアクセスする方法、Build.ioによるデータの取り扱いまで、セキュリティはサービスの中核を成しています。

この章では、Build.ioアカウントの保護、チームのアクセス管理、アプリケーションを安全に保つためのベストプラクティスを説明します。

10.1 認証とアクセス制御

Build.ioには2つのログイン方法があります：

メールアドレスとパスワード — メールアドレスと強力なパスワードでBuild.ioアカウントを作成します。パスワードはパスワードマネージャーで生成・保存し、他のサービスで使っているものを使い回さないようにします。二要素認証を有効にすると、アカウントをさらに強固に保護できます（セクション10.3を参照）。

Google SSO — Googleアカウントでログインでき、ログインの手順がシンプルになります。Google Workspaceをすでに使っているチームには特に便利で、既存のGoogle管理ポリシーを通じてID管理を一元化できます。

API認証

CLIやプラットフォームAPIを通じてプログラムからBuild.ioを操作する場合は、APIトークンで認証します。APIトークンはアカウントに紐付いており、ダッシュボードでの自分の権限と同じ権限を持ちます。

APIトークンの生成と管理は、アカウント設定から行います。APIトークンはパスワードと同じように扱います。リポジトリにはコミットせず、暗号化されていない経路では共有せず、定期的にローテーションしてください。トークンが漏洩した疑いがある場合は、アカウント設定からただちに失効させ、新しいトークンを生成します。

CLI認証

bld CLIは、マシンにローカル保存したAPIトークンで認証します。初めてbld loginを実行するとブラウザで認証が行われ、発行されたトークンをCLIが保存します。共有マシンやCIマシンでは、対話形式のログインを実行する代わりにBUILD_API_KEY環境変数を設定します。または、~/.netrcファイルを作成（または更新）し、loginにユーザー名、passwordにAPIキーを指定する方法もあります。bld CLIはこのファイルを読み取って認証します。

10.2 チーム管理と権限

アプリケーションの多くはチームで開発されます。Build.ioはロールベースのアクセス制御を備えているため、チームメンバーごとに適切なレベルのアクセス権を付与できます。

チーム

チームは、Build.ioで共同作業を行うときの最上位の単位です。チームはアプリ、パイプライン、アドオンを所有し、ロールが定められたメンバーで構成されます。チームを使えば、本番インフラを特定の個人アカウントに結び付けず、共同で所有できます。

ロール

ロールは次の2つです：

管理者（Admin） — 組織とそのアプリ、請求、メンバーを完全に管理できます。メンバーの追加と削除、ロールの変更、アプリの作成と削除を行えます。管理者の数は少なく抑えてください。ほとんどのチームメンバーには、ここまでのアクセス権は必要ありません。

メンバー（Member） — アプリの作成、デプロイ、Config Varの管理、アドオンのアタッチなど、日常の開発作業に必要な操作はすべて行えます。ただし、他のメンバーの追加や削除はできません。

アクセス管理

メンバーは、ダッシュボードの組織設定から追加します。新しくチームに加わる人は、管理者権限が特に必要な場合を除き、メンバーとして追加します。チームを離れる人のアクセス権は速やかに削除し、使われなくなったアカウントが本番インフラへのアクセス権を持ったまま残らないようにします。

組織のメンバーリストは定期的に見直してください。アクセス権は時間とともに積み重なりがちです。請負業者の入れ替わりがあるチームや、部門をまたいで協力していた人がもうアクセス権を必要としていないチームでは、特にその傾向があります。

10.3 二要素認証

二要素認証（2FA）は、ログイン時にパスワードに加えて2つ目の認証ステップを求める仕組みです。パスワードが漏洩しても、攻撃者は2つ目の要素がなければアカウントにアクセスできません。

2FAの有効化

2FAは、Build.ioダッシュボードのアカウントのセキュリティ設定から有効にします。対応しているのは、時間ベースのワンタイムパスワード（TOTP）を生成する認証アプリ（Google Authenticator、Authy、1Passwordなど）です。2FAを有効にすると、ログインのたびに認証アプリのコードの入力を求められます。

セットアップ時には、Build.ioからバックアップ用のリカバリーコードが発行されます。認証アプリにアクセスできなくなったときの予備手段になるため、認証アプリとは別の安全な場所に保管してください。リカバリーコードはそれぞれ1回しか使えません。

チームでの2FA

チームをBuild.ioで管理している場合は、組織の全メンバーに2FAの利用を義務付けることを強く推奨します。アカウントが1つ乗っ取られただけで、本番インフラ全体（Config Var、データベースの認証情報、デプロイ権限など、そのアカウントから到達できるすべて）が危険にさらされるおそれがあります。組織全体で2FAを必須にすることは、最も効果の高いセキュリティ対策の1つです。

10.4 コンプライアンスと認定

Build.ioは、米国（東部・西部）、西ヨーロッパ、日本の主要なインターネットハブにあるTier 4データセンターで運用されています。インフラは、本番SaaSアプリケーションを開発するチームのセキュリティ要件を満たすように設計されています。

セキュリティチーム

Build.ioのチームには、Cloud Native Computing Foundation傘下のものを含む著名なセキュリティツールやプロジェクト（Metasploit、Kubernetes、Ciliumなど）のコアコントリビューターが在籍しています。スタッフには、CISSP認定の専門家とCREST CRT認定のペネトレーションテスターが複数います。セキュリティは外部に委託せず、プラットフォームを開発・運用するチーム自身が担っています。

インフラのセキュリティ

Build.ioは、セキュリティを強化したデフォルト設定のKubernetes上で動作しています。アプリケーションのコンテナは、権限を制限した独立のネームスペースで実行されます。ネットワークポリシーによってテナント間は厳密に分離されており、アプリのトラフィックが他の顧客のワークロードに届くことはありません。

すべてのデータは、転送時にはTLSで、保存時にはAES-256で暗号化されます。Config Var、データベースの認証情報、その他のシークレットは、ライフサイクルのどの段階でも暗号化されています。

コンプライアンス

組織に特定のコンプライアンス要件（SOC 2、ISO 27001、GDPR、業界固有の規制など）がある場合は、support@build.ioまでお問い合わせください。コンプライアンス体制をBuild.ioがどのように支援できるかをご相談いただけます。監査や評価に必要であれば、セキュリティ管理策、データの取り扱い方法、インフラのアーキテクチャについて詳しい情報を提供します。

10.5 セキュリティのベストプラクティス

ここでは、Build.io上のアプリケーションを安全に保つうえで特に効果の大きい対策を紹介します。

アカウントを保護する

組織内のすべてのBuild.ioアカウントで二要素認証を有効にします（セクション10.3を参照）。パスワードマネージャーを使い、パスワードは使い回さないでください。組織のメンバーリストを定期的に見直し、使われていないアカウントは削除します。こうした基本を押さえるだけで、アカウントを狙った攻撃の大半を防げます。

コードからシークレットを排除する

APIキー、データベースのパスワード、暗号化キーなどの認証情報は、決してリポジトリにコミットしないでください。シークレットはConfig Var（セクション4.1を参照）を使って実行時に渡します。誤ってシークレットをコミットした場合は、その時点で漏洩したものとして扱います。コミットを削除するだけでは不十分で、認証情報のローテーションが必要です。Gitの履歴は永久に残り、すでにクローンやキャッシュされている可能性もあるためです。

最初のコミットより前に、.envファイルを.gitignoreに追加しておきます。git-secretsやpre-commitフックなどのツールを使えば、認証情報を誤ってコミットしても、プッシュする前に検出できます。

定期的に認証情報をローテーションする

シークレットのローテーションは、侵害が起きるのを待たずに行います。スケジュールを決め（多くのチームでは四半期ごとが妥当な出発点です）、APIキー、データベースのパスワード、その他の長期間使う認証情報をローテーションします。Config Varの更新手順（セクション4.3を参照）を使えば、ローテーションを簡単に行えます。

ローテーションの際は、まずConfig Varを新しい認証情報に更新し、アプリが正常に動作することを確認してから古い認証情報を失効させます。複数の認証情報を同時に有効にできるサービスであれば、ダウンタイムなしでローテーションできます。

依存関係を最新に保つ

古い依存関係は、最もよく狙われる攻撃経路の1つです。各言語の依存関係監査ツール（Rubyならbundle audit、Node.jsならnpm audit、Pythonならpip-audit）を使い、見つかった脆弱性には速やかに対処します。Dependabotなどの自動化ツールは、脆弱な依存関係に対してプルリクエストを作成できます。その更新は、Build.ioのパイプラインとレビューアプリを使えば、本番環境に届く前に手軽にテストできます。

Webアプリケーションファイアウォールを使用する

パブリックインターネットに公開するアプリでは、Build.ioに組み込まれたWAFを有効にします（セクション4.2を参照）。WAFは、SQLインジェクションやクロスサイトスクリプティングといった一般的な攻撃パターンをブロックします。必要な設定はわずかで、パフォーマンスへの影響もほとんどありません。安全なアプリケーションコードの代わりにはなりませんが、自動化された攻撃や無差別なスキャンに対する有効な防御層になります。

攻撃対象領域を最小化する

公開するのは、公開が必要なものだけにします。パブリックインターネットから到達できる必要がないサービスには、パブリックURLを割り当てないでください。使っていない機能やエンドポイントは無効にします。開いているポート、公開エンドポイント、有効になっているサービスは、どれも侵入口になり得ます。