10. セキュリティ

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

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

10.1 認証とアクセス制御

Build.ioは2つのサインイン方法をサポートしています：

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

Google SSO — Googleアカウントでサインインして、シームレスなログインエクスペリエンスを得られます。これはGoogle Workspaceをすでに使用しているチームに特に便利で、既存のGoogle管理ポリシーを通じてアイデンティティ管理を一元化できます。

API認証

CLIまたはプラットフォームAPIを通じてBuild.ioとプログラム的に連携する場合は、APIトークンを使用して認証します。APIトークンはアカウントに紐付けられ、ダッシュボードと同じ権限を持ちます。

アカウント設定からAPIトークンを生成・管理します。APIトークンはパスワードと同様に扱ってください。リポジトリにコミットしない、暗号化されていないチャネルで共有しない、定期的にローテーションする。トークンが侵害されたと思われる場合は、アカウント設定からすぐに失効させ、新しいものを生成してください。

CLI認証

bld CLIは、マシンにローカルに保存されたAPIトークンを使用して認証します。最初にbld loginを実行すると、ブラウザ経由で認証し、CLIが結果のトークンを保存します。共有マシンやCIマシンでは、インタラクティブなログインを実行するのではなく、BUILD_API_KEY環境変数を設定してください。あるいは、ログインをユーザー名、パスワードをAPIキーとして~/.netrcファイルを作成または更新することもできます。bld CLIツールはこのファイルを読み取って適切に認証します。

10.2 チーム管理と権限

ほとんどのアプリケーションはチームでビルドされ、Build.ioはロールベースのアクセス制御を提供するため、各チームメンバーに適切なレベルのアクセスを付与できます。

チーム

チームはBuild.ioでのチームコラボレーションのトップレベルの単位です。チームはアプリ、パイプライン、アドオンを所有し、定義されたロールを持つメンバーがいます。チームを使用することで、本番インフラが個人のアカウントに縛られるのではなく、共有された所有権のもとに置かれます。

ロール

Build.ioには2つのロールがあります：

管理者（Admin） — 組織、アプリ、請求、メンバーへの完全なコントロール。管理者はメンバーの追加・削除、ロールの変更、アプリの作成・削除ができます。管理者の数を少なく保ってください。ほとんどのチームメンバーにはこのレベルのアクセスは不要です。

メンバー（Member） — アプリの作成、デプロイ、設定変数の管理、アドオンのアタッチ、その他の日常的な開発作業に必要なすべてを行えます。メンバーは他のメンバーを追加・削除することはできません。

アクセス管理

ダッシュボードの組織設定からメンバーを追加します。誰かがチームに参加する場合、管理者権限が特に必要でない限りメンバーとして追加します。誰かが退職した場合は、すぐにアクセスを削除してください。非アクティブなアカウントが本番インフラへのアクセスを持ったままにしないでください。

定期的に組織のメンバーリストを見直してください。特に請負業者の入れ替わりや、もはやアクセスが不要なクロスファンクショナルなコラボレーターがいるチームでは、時間の経過とともにアクセスが蓄積しがちです。

10.3 二要素認証

二要素認証（2FA）は、サインイン時にパスワードに加えて2番目の認証ステップを追加します。パスワードが侵害されても、攻撃者は2番目の要素なしにアカウントにアクセスできません。

2FAの有効化

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

セットアップ中、Build.ioはバックアップリカバリーコードを提供します。これらを認証アプリとは別の安全な場所に保管してください。認証アプリへのアクセスを失った場合のフォールバックです。各リカバリーコードは1回のみ使用できます。

チームでの2FA

Build.ioでチームを管理している場合は、すべての組織メンバーに2FAの使用を強く検討してください。1つの侵害されたアカウントが、本番インフラ全体（設定変数、データベース認証情報、デプロイアクセス、そのアカウントが到達できるすべてのもの）を露出させる可能性があります。組織全体で2FAを必須にすることは、最も影響の大きなセキュリティ対策の一つです。

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

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

セキュリティチーム

私たちのチームには、Metasploit、Kubernetes、CiliumなどのCloud Native Computing Foundationのもとでの著名なセキュリティツールとプロジェクトの主要貢献者が含まれています。複数のCISSP認定の専門家とCREST CRT認定のペネトレーションテスターがスタッフにいます。セキュリティは外注されておらず、プラットフォームを構築・運営するチームの一部です。

インフラのセキュリティ

Build.ioはセキュリティが強化されたデフォルト設定のKubernetesで動作します。アプリケーションのコンテナは制限された権限を持つ独立したネームスペースで実行されます。ネットワークポリシーはテナント間の厳格な分離を強制します。あなたのアプリのトラフィックは他のお客様のワークロードに到達できません。

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

コンプライアンス

組織に特定のコンプライアンス要件（SOC 2、ISO 27001、GDPR、または業界固有の規制）がある場合は、support@build.ioのチームにご連絡いただき、Build.ioがどのようにコンプライアンス体制をサポートできるかについて話し合ってください。監査と評価に必要なセキュリティコントロール、データ処理の慣行、インフラアーキテクチャの詳細を提供できます。

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

Build.io上でアプリケーションを安全に保つために最も効果的なことを紹介します。

アカウントを保護する

組織内のすべてのBuild.ioアカウントで二要素認証を有効にします（セクション10.3を参照）。パスワードマネージャーを使用します。パスワードを使い回しません。定期的に組織のメンバーリストを見直し、非アクティブなアカウントを削除します。これらの基本事項はアカウントベースの攻撃の大部分を防ぎます。

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

APIキー、データベースパスワード、暗号化キー、その他の認証情報をリポジトリにコミットしないでください。設定変数（セクション4.1を参照）を使用して実行時にシークレットを注入します。シークレットを誤ってコミットした場合は、すぐに侵害されたとみなしてください。コミットを削除するだけでなく、認証情報をローテーションしてください。Gitの履歴は永続的であり、すでにクローンまたはキャッシュされている可能性があります。

最初のコミットの前に.envファイルを.gitignoreに追加します。プッシュされる前に誤った認証情報のコミットを検出するためにgit-secretsやpre-commitフックなどのツールを使用します。

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

侵害を待ってシークレットをローテーションしないでください。スケジュールを設定します。ほとんどのチームにとって四半期ごとが合理的な出発点です。APIキー、データベースパスワード、その他の長期的な認証情報をローテーションします。ローテーションを簡単にするために設定変数の更新プロセス（セクション4.3）を使用します。

ローテーション時には、設定変数に新しい認証情報を更新してアプリが動作することを確認してから古い認証情報を失効させます。一部のサービスは複数のアクティブな認証情報を同時にサポートしており、ダウンタイムなしのローテーションが可能です。

依存関係を最新に保つ

古い依存関係は最も一般的な攻撃ベクターの一つです。言語の依存関係監査ツール（RubyのBundle Audit、Node.jsのNPM Audit、PythonのPIP-Audit）を使用し、脆弱性に迅速に対処します。DependabotなどのAutomatedツールは脆弱な依存関係に対してPRを開くことができ、Build.ioのパイプラインとレビューアプリにより、それらの更新を本番環境に到達する前にテストすることが容易になります。

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

パブリックインターネットに公開されているアプリには、Build.ioの組み込みWAFを有効にします（セクション4.2を参照）。WAFは最小限の設定とほぼ無視できるパフォーマンスへの影響で、SQLインジェクションやクロスサイトスクリプティングなどの一般的な攻撃パターンをブロックします。セキュアなアプリケーションコードの代替ではありませんが、自動化された攻撃と日和見的なスキャンに対する意味のある防御層を提供します。

攻撃対象面を最小化する

公開が必要なものだけを公開します。サービスがパブリックインターネットから到達可能である必要がない場合は、パブリックURLを与えないでください。使用しない機能とエンドポイントを無効にします。すべての開いているポート、パブリックエンドポイント、有効なサービスは潜在的なエントリポイントです。