セキュリティ対策について
Auth-Shareは、パスワード、APIキー、アクセストークンなどの重要情報を、個人ではなく組織の資産として安全に管理するためのサービスです。
情報の保存方法だけでなく、ログイン、アクセス権限、操作履歴、バックアップ、サーバー管理まで含めた複数の対策を組み合わせています。
本ページでは、Auth-Shareで実施している主なセキュリティ対策と運用方針について説明します。
セキュリティ設計の基本方針
Auth-Shareでは、単一の対策だけに依存せず、複数の防御策を組み合わせる多層的なセキュリティ設計を採用しています。
主に次の観点から、組織の重要情報を保護します。
- 保存データの暗号化
- 組織単位のデータ分離
- ユーザー・グループ単位のアクセス制御
- 2要素認証を含むログイン保護
- 一定時間経過後の自動ログアウト
- シークレットおよび管理操作の履歴記録
- サーバー管理権限の制限
- 管理アクセスの監視・記録
- 定期的なバックアップ
シークレットの暗号化保存
Auth-Shareに登録されたパスワード、APIキー、トークンなどのシークレットは、平文のままデータベースへ保存されません。
シークレットの値はアプリケーション側で暗号化してから保存され、閲覧権限を持つユーザーがAuth-Share上で閲覧するときにのみ復号されます。
そのため、データベースの保存内容だけを直接確認しても、シークレットの内容をそのまま読み取ることはできません。
暗号化の対象
主に以下のような情報を暗号化して保存します。
- パスワード
- APIキー
- アクセストークン
- 認証用文字列
- メモや接続情報などの秘匿情報
- シークレットの変更履歴に保存される値
暗号化された情報を復号するために必要な情報についても、データベースとは分離して管理しています。
組織単位のデータ分離
Auth-Shareでは、利用組織ごとにデータの管理範囲を分離しています。
ユーザーは所属している組織の情報だけを利用でき、別の組織に所属するユーザーやシークレットへアクセスできないよう制御しています。
組織ごとに専用のログイン空間が設けられ、ユーザー、グループ、シークレット、権限、履歴などのデータを組織単位で管理します。
ユーザー・グループ単位の権限管理
すべてのユーザーが、組織内のすべてのシークレットを閲覧できるわけではありません。
シークレットごとに、アクセスできるユーザーまたはグループを設定できます。
また、閲覧だけを許可する権限と、内容の変更まで許可する権限を分けて管理できます。
権限の考え方
- 業務上必要なユーザーだけにアクセスを許可
- 閲覧権限と編集権限を分離
- グループ単位で複数ユーザーへ権限を付与
- 外部ユーザーには必要最小限の範囲だけを共有
- 退職、異動、契約終了時にユーザーのアクセスを停止
必要以上の情報へアクセスさせない、最小権限の考え方を基本としています。
ユーザー種別による権限分離
Auth-Shareでは、利用者の役割に応じてユーザー種別を分けています。
管理ユーザー
組織内のユーザー、グループ、招待、権限などを管理します。
社内ユーザー
社内でシークレットを利用するユーザーです。付与された権限の範囲で閲覧・編集できます。
外部ユーザー
取引先や業務委託先など、組織外の関係者を想定したユーザーです。必要なシークレットだけを限定して共有できます。
管理機能と日常利用の権限を分けることで、すべてのユーザーへ過剰な管理権限を付与しない設計としています。
2要素認証
Auth-Shareは2要素認証に対応しています。
2要素認証を利用すると、メールアドレスとパスワードだけではログインできず、追加の認証情報が必要になります。
そのため、パスワードが第三者に知られた場合でも、アカウントへ不正にログインされるリスクを低減できます。
重要情報を扱うユーザー、特に管理ユーザーには2要素認証の利用を推奨しています。
外部認証プロバイダーとの連携
Auth-Shareは、対応している外部認証プロバイダーを利用したログインにも対応しています。
外部認証を利用する場合、認証処理の一部を信頼できる認証プロバイダーへ委ねることで、ユーザーが管理するパスワードを増やさずにログインできます。
組織の運用方針に応じて、通常のログイン方法と外部認証を選択できます。
ログイン状態の有効期限
ログインした状態が長時間残り続けないよう、Auth-Shareでは時間による制限を設けています。
- 30分間操作がない場合は自動的にログアウト
- ログイン後、最長8時間で再ログインが必要
これにより、ログインしたままの端末が放置された場合や、共有端末でログアウトを忘れた場合のリスクを抑えます。
シークレットの変更履歴
シークレットの作成、変更、削除などの操作は履歴として記録されます。
履歴には、操作を行ったユーザー、操作日時、操作内容などが記録されます。
シークレットの値を履歴として保存する場合も、現在のシークレットと同様に暗号化して保存します。
履歴管理の目的
- 誰が変更したかを確認する
- いつ変更されたかを確認する
- 誤操作や意図しない変更を調査する
- 必要に応じて過去の状態を確認する
- 変更前の状態へ復元する
シークレットを上書きするだけではなく、変更の経緯を追跡できる設計としています。
管理操作の監査履歴
管理ユーザーによる、ユーザー管理、グループ管理、権限変更など、組織全体に影響する操作についても履歴を記録します。
これにより、各管理ユーザーがいつ、どの管理操作を行ったかを後から確認できます。
監査履歴は、次のような用途を想定しています。
- 管理操作の確認
- 権限変更の経緯の調査
- 誤操作発生時の原因確認
- 内部監査や運用状況の確認
- 不審な操作の調査
管理ユーザーであっても、記録を残さずに重要な設定を変更することがないよう設計しています。
サーバーのアクセス制御
重要情報を保管するサーバーは、多層的なアクセス制御と複数人による承認体制で保護しています。
開発・運用担当者が、通常時に自由な操作を行える状態にはしていません。
日常的な保守作業は、あらかじめ安全性を確認して許可した操作に限定しています。任意のコマンドを自由に入力する方式ではなく、用途ごとに定められた操作だけを実行する運用です。
より強い管理権限が必要な場合は、担当者自身の判断だけでは利用できず、別の権限管理者による一時的な許可を必要とします。
これにより、担当者のアカウントだけが不正利用された場合や、担当者による誤操作・不正操作のリスクを抑えます。
サーバー管理における権限分離
サーバー管理では、作業を実施する担当者と、強い権限を付与できる権限管理者を分けています。
通常時
- サーバーへの直接的な管理アクセスを制限
- 実行可能な保守操作を事前に許可したものに限定
- 操作の実行履歴を記録
- 人間用の管理権限を必要最小限に制限
強い管理権限が必要な場合
- 担当者だけの判断では権限を利用できない
- 別の権限管理者が一時的に権限を付与
- 管理アクセスおよび操作の発生を監視・記録
- 作業終了後に一時権限を解除
一人の担当者に、作業の実施と強い権限の付与を集中させない運用としています。
管理アクセスの監視・記録
サーバーに対する管理アクセスや重要な操作は、監視・記録の対象としています。
強い管理権限を利用した操作が発生した場合は、操作ログを外部のログ管理基盤へ送信します。
また、管理操作の発生を検知し、関係者へ通知する仕組みを設けています。
この仕組みにより、担当者以外が管理権限を利用した場合や、想定していない時間帯に操作が行われた場合も、後から確認できます。
なお、この監視はサーバーに対する管理アクセスと重要操作を対象とするものです。すべての種類のサイバー攻撃を自動的に検知・防止することを意味するものではありません。
通常時の直接ログインを禁止
本番用のサーバーでは、インターネットからの一般的なリモートログイン用ポートを開放していません。
通常の管理作業は、認証・認可された管理経路と、事前に許可された操作を通じて実施します。
これにより、公開された管理用ポートを探索して侵入を試みる攻撃や、管理用の秘密鍵が漏えいした場合のリスクを抑えています。
詳細な接続方式、権限構成、識別情報については、安全上の理由から公開していません。
バックアップ
Auth-Shareのデータベースは毎日バックアップしています。
バックアップは、次のような事態からの復旧を目的としています。
- サーバーやストレージの障害
- データベース障害
- アプリケーションの不具合
- 誤操作によるデータの変更・削除
- その他の予期しないデータ消失
バックアップだけに依存せず、アプリケーション内の履歴管理と組み合わせてデータを保護しています。
退職・異動時の情報保護
Auth-Shareは、重要情報を個人の所有物ではなく、組織の資産として管理することを重視しています。
担当者が退職・異動した場合でも、組織に登録されたシークレットは組織内に残ります。
管理ユーザーは、対象ユーザーの利用停止や権限変更を行い、必要なユーザーへアクセス権限を引き継ぐことができます。
これにより、次のような問題を防ぎます。
- 退職者しかパスワードを知らない
- 個人のブラウザやメモにしか情報がない
- 担当変更時に認証情報が引き継がれない
- 外部委託の終了後もアクセス権限が残る
- 共有相手や利用目的が分からなくなる
Auth-Shareは、重要な認証情報を失わせないことと、不要になったアクセス権限を残さないことの両方を重視しています。
インフラストラクチャの分離
Auth-Shareでは、アプリケーションを稼働させる環境と、データベースを役割ごとに分離しています。
アプリケーションとデータベースの両方へ無条件にアクセスできる状態を避け、それぞれの通信経路と管理権限を制限しています。
シークレットの暗号化情報、データベース、復号に必要な情報が単一の場所だけで完結しないよう、複数の管理領域へ分けて保護しています。
開発・運用時の操作制限
本番環境での保守操作は、用途に応じて分類しています。
通常の確認操作
サーバーやアプリケーションの状態確認などは、事前に定義した安全な操作だけを実行できる仕組みを利用します。
データベース変更
データベース構造を変更する処理は、通常の確認操作とは分離し、専用の手順で実施します。
アプリケーション管理コマンド
アプリケーションの管理コマンドについても、自由入力ではなく、事前に許可したコマンドだけを実行できるよう制限しています。
危険性の高い操作や、機密情報を表示する可能性がある操作は、通常の実行候補に含めていません。
機密情報をログへ出力しないための対策
操作ログやアプリケーションログは、障害調査や監査に必要です。
一方で、ログ自体にシークレットや認証情報を出力すると、新たな情報漏えい経路になる可能性があります。
そのため、次の情報を不用意にログへ出力しないことを運用上の原則としています。
- パスワード
- APIキー
- アクセストークン
- 暗号鍵
- データベースの認証情報
- セッション情報
- 認証用Cookie
- シークレットの復号結果
監視通知にもログ本文をそのまま含めず、管理操作が発生した事実を通知する設計を基本としています。
公的ガイドラインとの関係
Auth-Shareでは、以下のような公的な情報セキュリティガイドラインでも重視されている対策を取り入れています。
- アクセス権限の制御
- 多要素認証
- 操作ログの記録
- 権限の分離
- バックアップ
- 不要な管理経路の制限
- 重要操作の監視
- インシデント発生時に確認できる記録の保存
ただし、現時点でISO/IEC 27001などの第三者認証を取得していることを示すものではありません。
特定の認証規格への適合を表明するのではなく、Auth-Shareに必要なリスクを確認しながら、実効性のある対策を継続的に追加・改善しています。
セキュリティ対策の継続的な見直し
Auth-Shareでは、サービスの変更や新たな脅威に対応するため、セキュリティ対策を継続的に確認・見直しています。
認証、アクセス制御、暗号化、操作記録、バックアップなどの対策について、運用状況を確認しながら必要な改善を行います。
利用組織にお願いする対策
Auth-Share側の対策だけでなく、利用者側での安全な運用も重要です。
次の対策を推奨します。
- 2要素認証を有効にする
- 組織で管理している信頼できる外部IdPを利用し、認証やアカウント管理を一元化する
- 他のサービスと同じパスワードを使い回さない
- 管理ユーザーを必要最小限にする
- 退職者・異動者のアカウントを速やかに停止する
- 外部ユーザーの権限を定期的に確認する
- 不要になった共有権限を削除する
- 不審なログインや操作を確認した場合は管理者へ連絡する
- 共用端末では利用後にログアウトする
セキュリティ上の制限
Auth-Shareは、情報漏えい、アカウントの不正利用、誤操作、データ消失などのリスクを低減するための対策を実施しています。
ただし、いかなるシステムでも、すべての攻撃や障害を完全に防止することはできません。
また、以下のような利用者側の管理状態によっては、安全性が低下する可能性があります。
- 認証情報を第三者へ共有する
- 2要素認証を利用しない
- ログイン済み端末を第三者へ渡す
- 必要以上のユーザーへ権限を付与する
- 退職者や契約終了者のアカウントをブロック・削除せず、利用可能な状態にしておく
- シークレットをAuth-Share以外の安全でない場所にも保存する
Auth-Shareは、技術的な対策と適切な組織運用を組み合わせることで、安全性を高めるサービスです。
セキュリティに関するお問い合わせ
Auth-Shareのセキュリティ対策、法人導入時の運用、権限設計などについて確認したい場合は、お問い合わせ窓口からご連絡ください。
セキュリティ上の問題や脆弱性と思われる事象を発見した場合も、詳細を一般公開せず、まずお問い合わせ窓口までご連絡ください。