# Junify

> Junify は、パスワードを渡さずに社内外の担当者へ仕事を任せるためのアクセス管理サービスです。担当者はスマホで本人認証し、カードをクリックするだけで必要なアカウントにログインできます。パスワードは開示されず、誰がいつどのアカウントを使ったかは個人単位で記録されます。

このサイトの日本語ページは、同じ内容の Markdown でも配信しています。各ページの URL に `.md` を付けるか、
`Accept: text/markdown` を付けてリクエストしてください。

## ページ

- [Junify — アカウントを渡さず、仕事を任せる](https://www.junify.jp/index.md): 日本語トップページ。解決する問題、導入後の状態、仕組み、現場別の入口。
- [BPO・運用代行向けのご案内](https://www.junify.jp/bpo.md): 共有・代理アカウントの課題、仕組み、既存の道具との違い、料金、導入の流れ、FAQ。
- [30 分デモを予約する](https://www.junify.jp/bpo/demo.md): デモで扱う内容と、申し込みに必要な項目。
- [資料をダウンロード](https://www.junify.jp/bpo/download.md): ご説明資料(PDF)の内容と入手方法。
- [医療・ヘルスケア向けのご案内](https://www.junify.jp/healthcare.md): スポット勤務の医師・私物端末・委託先を含む診療システムのアクセス管理。導入後の状態、仕組み、医療の現場で効くこと、FAQ。
- [クラウド運用・特権 ID向けのご案内](https://www.junify.jp/privileged-access.md): 管理コンソール・管理者用 ID のアクセス管理。担当者にパスワードを渡さず、誰が・いつ・どのコンソールに入ったかを一人ひとり記録。IP 制限も管理画面の設定もそのまま。いまの運用、仕組み、導入後の状態、FAQ。
- [SNS・広告・EC 運用代行向けのご案内](https://www.junify.jp/marketing-ops.md): クライアントから預かった SNS 公式・広告・EC モールのアカウントを、担当者にパスワードを渡さずに使ってもらう。いまの運用、仕組み、導入後の状態、自社のアカウントの方への案内、FAQ。
- [人事・採用向けのご案内](https://www.junify.jp/hr.md): 採用媒体と人事系サービスの共有アカウントを、担当者ごとの入口と記録に。導入後の状態、仕組み、人事システム連携、FAQ。
- [社内の共有アカウント向けのご案内](https://www.junify.jp/shared-accounts.md): 部門に残る共有アカウントを、廃止せずに本人単位の入口と記録に。SSO との併用、IdP との違い、FAQ。
- [Junify の仕組み](https://www.junify.jp/product.md): パスワードを渡さずにログインさせる仕組み。3 ステップの使い方、管理者ができること、端末の条件、既存の IdP との共存。
- [作っている人たち](https://www.junify.jp/about.md): 創業ストーリー(楽天の 11 番目の社員として技術部門を率いた元 CTO が 2016 年に設立)、チーム、日本のお客様への対応、信頼の根拠、会社概要。
- [お問い合わせ](https://www.junify.jp/contact.md): お問い合わせフォームの項目と、メールでの連絡先。

## Junify の使い方

- [招待メールから Junify に参加する](https://www.junify.jp/help/member/join-via-email.md): 届いた招待メールから、スマートフォンの Junify のアプリで登録を済ませ、招待された組織に参加できます。
- [6 桁のコードで Junify に参加する](https://www.junify.jp/help/member/join-via-code.md): 管理者から受け取った 6 桁のコードを使い、スマートフォンの Junify のアプリで登録を済ませて、招待された組織に参加できます。
- [Junify からのメールがスパムフィルターにかかってしまう場合の対処方法](https://www.junify.jp/help/member/allow-junify-email.md): Junify からの重要な認証コードなどのメールが、G-Suite のスパムフィルターによって、スパムのフォルダに振り分けられ、オペレーションがスムーズに進まない場合があります。
- [勤務の開始と終了を記録する](https://www.junify.jp/help/member/clock-in-out.md): スマートフォンの Junify のアプリのホーム画面で、仕事を始めたときと終えたときを勤務の記録に残せます。
- [勤務中の位置情報を共有する](https://www.junify.jp/help/member/share-location.md): スマートフォンの Junify のアプリに位置情報の利用を許可して勤務を始めると、勤務中の居場所を組織に共有できます。
- [PCで Junify にログインをする](https://www.junify.jp/help/member/log-in-on-pc.md): パソコンで Junify にログインするには、初期設定を済ませた Junify アプリと、Chrome ブラウザを用意してください。
- [カードからアプリにログインする](https://www.junify.jp/help/member/card-login.md): Junify の画面で仕事のアプリのカードを押すと、パスワードを自分で入れずに、そのアプリにログインできます。
- [スマートフォンでカードからアプリにログインする](https://www.junify.jp/help/member/open-application-card.md): スマートフォンの Junify のアプリで仕事のアプリのカードをタップすると、パスワードを自分で入れずに、そのアプリにログインできます。
- [組織の情報と設定を確かめる](https://www.junify.jp/help/admin/set-up-organization.md): 組織の名前や連絡先と、組織全体にかかる Junify の設定が、今どうなっているかを確かめられます。
- [メールでメンバーを招待する](https://www.junify.jp/help/admin/invite-member.md): 新しく入った人に招待のメールを送り、スマートフォンの Junify のアプリで登録してもらえるようにします。
- [仕事で使うアプリを Junify に登録する](https://www.junify.jp/help/admin/register-app.md): 仕事で使うアプリを Junify に登録し、メンバーに渡すカードを作れるようにします。
- [アプリのカードを作ってメンバーに渡す](https://www.junify.jp/help/admin/assign-card.md): アプリのカードを作って使う人を選ぶと、その人は Junify の画面に出るカードから、そのアプリにログインできます。
- [自分のグループのメンバーを見る](https://www.junify.jp/help/group-leader/view-supervised-groups.md): 自分がグループリーダーを務めるグループのメンバーを一覧で見て、一人ずつ登録内容を確かめられます。
- [バックアップ用のメールアドレスを登録する](https://www.junify.jp/help/member/register-backup-email.md): スマートフォンの Junify のアプリに個人のメールアドレスを登録し、アカウントを新しいスマートフォンに戻すためのメールを受け取れるようにします。
- [スマートフォンを忘れた／紛失の場合の緊急手段](https://www.junify.jp/help/member/use-backup-login.md): Junify アプリを入れたスマートフォンを一時的に忘れた、Junify アプリをうっかり削除してしまった、スマートフォンを紛失した、という場合に、普段お使いのパソコンから緊急でログインする方法を紹介します。
- [Chrome 拡張機能の削除／再インストール](https://www.junify.jp/help/member/reinstall-extension.md): Junify をパソコンでお使いの場合は Chrome ブラウザにおいて拡張機能を利用します。
- [新しいスマートフォンに自分のアカウントを戻す](https://www.junify.jp/help/member/restore-account.md): 管理者から受け取った 6 桁のコードで、これまでのアカウントを新しいスマートフォンの Junify のアプリに戻せます。
- [Junify アプリの初期化を行う](https://www.junify.jp/help/member/reset-app.md): 一度 Junify アプリを利用していた端末を他人に渡して別の Junify アカウントとして使う場合には、端末に残されている情報を初期化する必要があります。
- [アプリの設定とカード、アカウントを確かめる](https://www.junify.jp/help/admin/manage-application-profile.md): 登録したアプリを開き、ログインの方法などの設定と、そのアプリのカードとアカウントを確かめられます。
- [共有アカウントの ID とパスワードを設定する](https://www.junify.jp/help/admin/set-up-account.md): 共有アカウントに ID とパスワードを保存しておくと、カードを渡した人はそのアプリにログインできます。アプリのパスワードが変わったときも、同じ手順で入れ直せます。
- [メンバーのアカウントのパスワードを会社で管理する](https://www.junify.jp/help/admin/control-passwords.md): メンバーのアカウントの ID とパスワードを、メンバーではなく会社の管理者が入れて管理するようにできます。
- [決めた場所からだけアプリを開けるようにする](https://www.junify.jp/help/admin/set-access-rules.md): アプリを開いてよい場所を決め、その場所にいるメンバーだけが開けるようにします。会社のネットワークからだけ開けるようにもできます。
- [Junify × Google Workspace SAML連携設定マニュアル](https://www.junify.jp/help/admin/set-up-google-workspace-saml.md): 本マニュアルでは、JunifyをIdPとし、Google Workspaceの新しい「SAMLプロファイル」機能を使用してSSO（シングルサインオン）を行うための設定手順を解説します。
- [電話番号でメンバーを招待する](https://www.junify.jp/help/admin/invite-member-by-phone.md): 新しく入った人を電話番号で招待します。画面に出る 6 桁のコードを伝えると、その人はスマートフォンの Junify のアプリで登録できます。
- [メンバーの退職処理をする](https://www.junify.jp/help/admin/offboard-member.md): 組織を離れる人を、Junify のメンバーから外します。
- [メンバーをグループに加える](https://www.junify.jp/help/admin/change-member-groups.md): メンバーを新しいグループに加えて、そのグループに渡しているアプリのカードも使えるようにします。
- [新しいスマートフォンにメンバーのアカウントを戻す](https://www.junify.jp/help/admin/restore-member-account.md): メンバーが新しいスマートフォンの Junify のアプリで、これまでのアカウントを続けて使えるようにします。
- [メンバーの情報を直す](https://www.junify.jp/help/admin/edit-member.md): メンバーの名前や電話番号、社員コードなどの登録内容を直して、保存できます。
- [グループリーダーを決める](https://www.junify.jp/help/admin/assign-group-leader.md): グループをまとめる人を選んで、グループリーダーにできます。
- [期限が切れた招待を送り直す](https://www.junify.jp/help/admin/resend-invitation.md): 招待の期限が切れ、まだ登録を済ませていない人に、招待をもう一度送ります。
- [スマートフォンを忘れたメンバーにログイン用のリンクを送る](https://www.junify.jp/help/admin/send-backup-login.md): スマートフォンを忘れたメンバーの個人用のメールアドレスに、一時的にログインできるリンクを送ります。メンバーは、スマートフォンがなくても勤務を記録できるようになります。
- [メンバーの位置情報を見る](https://www.junify.jp/help/admin/review-member-locations.md): メンバーが勤務中にどこにいて、どう移動したかを、時刻の順に確かめられます。登録した場所ごとに、いまその中にいる人数も分かります。
- [メンバーの勤務の記録を見る](https://www.junify.jp/help/admin/review-work-records.md): メンバーが何時に勤務を始め、何時に終えたかを、カレンダーで日ごとに確かめられます。
- [自分のグループのメンバーの位置情報を見る](https://www.junify.jp/help/group-leader/review-team-locations.md): 自分がリーダーを務めるグループのメンバーが勤務中かどうかと、いまいる場所を確かめられます。メンバーのその日のルートを、1 つの地図で見比べることもできます。
- [自分のグループのメンバーの勤務の状況を見る](https://www.junify.jp/help/group-leader/review-team-work-status.md): 自分がリーダーを務めるグループのメンバーが、いま勤務中かどうかを一覧で確かめられます。メンバーごとの勤務の記録も、月のカレンダーで見られます。
- [勤務時間の修正の申請を承認する](https://www.junify.jp/help/group-leader/approve-edit-request.md): メンバーから届いた勤務時間の修正の申請を、スマートフォンの Junify のアプリで確かめて承認できます。
- [アプリでの作業の録画をオンにする](https://www.junify.jp/help/admin/enable-recording.md): メンバーが Junify のカードからアプリを使ったときの作業を、録画するように設定できます。
- [作業の録画を見返す](https://www.junify.jp/help/admin/review-recording.md): アプリでの作業の録画を開き、誰がいつどのアプリで作業したかと、そのときの画面の動きを確かめられます。
- [誰がいつ何をしたかを記録から調べる](https://www.junify.jp/help/admin/search-events.md): 見たい期間とカテゴリで記録を絞り込み、誰がいつ何をしたかを一覧で確かめられます。
- [メンバーが使っているサービスを確かめる](https://www.junify.jp/help/admin/review-unapproved-apps.md): サービスごとに何人が使い、何回表示されたかを一覧で見て、そのサービスを誰が使ったかを確かめられます。
- [全体告知を書いて公開する](https://www.junify.jp/help/admin/post-announcement.md): 伝えたいことを全体告知として書いて公開し、組織のメンバーに知らせられます。
- [組織アカウント管理者を別の人に替える](https://www.junify.jp/help/admin/change-organization-owner.md): Junify の責任者が替わるときに、組織アカウント管理者を後任のメンバーに替えられます。
- [[初期設定] Zoomクライアントを設定する（パソコン／SAML認証）](https://www.junify.jp/help/member/set-up-sso.md): Junify は様々なアプリケーションと連動をして動きます。
- [Zoomで会議に参加する(パソコン)](https://www.junify.jp/help/member/join-meeting.md): パソコン上で Zoom クライアントを使用して会議を開催します。
- [Zoomで会議を開催する(パソコン)](https://www.junify.jp/help/member/host-meeting.md): パソコン上で Zoom クライアントを使用して会議を開催します。
- [Zoom 会議を予約して開催する （パソコン）](https://www.junify.jp/help/member/schedule-meeting.md): Junify は様々なアプリケーションと連動をして動きます。
- [[初期設定] Zoom アプリで SAML を用いた Junify との接続方法（スマートフォン）](https://www.junify.jp/help/member/set-up-sso-on-phone.md): [初期設定] Zoom アプリで SAML を用いた Junify との接続方法（スマートフォン）
- [Zoom app でミーティングに参加する（スマートフォン）](https://www.junify.jp/help/member/join-meeting-on-phone.md): Zoom app を用いて会議に参加します。
- [Zoom app で会議を開催する（スマートフォン）](https://www.junify.jp/help/member/host-meeting-on-phone.md): Zoom app を用いて会議を開催する方法です。
- [Zoom app での会議の事前予約・開催・削除をする方法（スマートフォン）](https://www.junify.jp/help/member/schedule-meeting-on-phone.md): Zoom app を用いて会議を事前に予約し、開催をする方法です。

## アカウント管理の基礎知識

- [共有アカウントの管理](https://www.junify.jp/guides/shared-accounts.md): 共有アカウントは、1 つの ID とパスワードを複数人で使う状態です。個人に分けられるものは分け、残るものは誰が使ったかを残せる方法で管理します。
- [1Password と Junify の違い、共有アカウントを担当者に見せずに使わせるときの使い分け](https://www.junify.jp/guides/shared-accounts/1password-and-junify.md): 社員それぞれのパスワードを保管して共有するなら 1Password が合います。共有アカウントを担当者に見せずに使わせ、外れた人をパスワードを変えずに止めたいなら Junify が合います。両方を分けて使うこともできます。
- [Bitwarden と Junify の違い、法人で共有アカウントを使わせるときの選び方](https://www.junify.jp/guides/shared-accounts/bitwarden-and-junify.md): 社員が自分のパスワードを保管し、信頼する同僚と共有するなら Bitwarden で足ります。共有アカウントを担当者に見せずに使わせ、外れた人をパスワードを変えずに止めたいなら Junify が合います。分けて併用もできます。
- [共有アカウントを管理する道具は、何を確かめて選ぶか](https://www.junify.jp/guides/shared-accounts/choosing-shared-account-tools.md): 先に、保管・使わせ方・記録のどれを管理したいかを分けます。そのうえで、担当者がパスワードを知るか、誰が使ったかが何か月残るか、人を外すときにパスワードを変えるか、二段階認証のコードを誰が受けるかを確かめます。
- [パスワードを見せない共有設定で、パスワードは守れるか](https://www.junify.jp/guides/shared-accounts/hidden-password-sharing-limits.md): 守れません。LastPass・1Password など 4 社の公式ヘルプはどれも、隠して共有しても、相手が取り出す余地は残ると書いています。共有した相手にはパスワードを渡したものとして扱い、外したらパスワードを変えます。
- [Keeper と Junify の違い、法人で共有アカウントを使わせるときの使い分け](https://www.junify.jp/guides/shared-accounts/keeper-and-junify.md): 社員が自分のパスワードを保管して共有するなら Keeper で足ります。共有アカウントを、Keeper のアカウントがない人も含めて見せずに使わせ、外れた人はパスワードを変えずに止めたいなら Junify が合います。併用もできます。
- [LastPass と Junify の違い、法人の共有アカウントを担当者に使わせるときの使い分け](https://www.junify.jp/guides/shared-accounts/lastpass-and-junify.md): 社員それぞれのパスワードを保管して共有フォルダーで配るなら LastPass が合います。共有アカウントをパスワードを見せずに使わせ、外れた人をパスワードを変えずに止めたいなら Junify が合い、LastPass の代わりにも使えます。
- [パスワードマネージャーから別の仕組みに移るとき、何を確かめるか](https://www.junify.jp/guides/shared-accounts/moving-off-password-manager.md): 移りたい理由を分け、保管庫の中身ごとに行き先を決めてから書き出します。製品や形式によってはパスキーなどが移らず、CSV などのファイルは暗号化されないので扱いを先に決めます。担当者に見せない仕組みへ移すなら、移すときにパスワードを変えます。
- [パスワードマネージャーで共有していた人が辞めるとき、何を止めて何を変えるか](https://www.junify.jp/guides/shared-accounts/password-manager-offboarding.md): 管理画面でその人を止め、使えた保管庫のパスワードをサービス側で変えます。共有した時点で本人にパスワードを渡したのと同じなので、止めるだけでは、見たパスワードでのログインは防げません。
- [Google スプレッドシートにパスワードはかけられるか](https://www.junify.jp/guides/shared-accounts/google-sheets-password-protection.md): かけられません。Google スプレッドシートには、Excel のように開くときにパスワードを求める設定がなく、見られる人は共有設定で決めます。ID とパスワードを書いた表は、開ける人なら誰でも値を読めます。
- [パスワードは何文字以上にすべきか(NIST・総務省・IPA の基準の違い)](https://www.junify.jp/guides/shared-accounts/password-length-recommendations.md): パスワードだけで入るなら NIST は 15 文字以上、二段階認証と組み合わせるなら 8 文字以上です。記号を混ぜる決まりは禁じています。IPA と総務省は 10 文字以上で、文字の種類を混ぜることを勧めています。
- [個人で使っているパスワードマネージャーに会社のパスワードを入れてよいか](https://www.junify.jp/guides/shared-accounts/personal-password-manager-at-work.md): 入れるのは避けたいところです。個人向けプランの保管庫は社員本人のもので、会社は中身を見られず、退職時に回収も削除の確認もできません。法人向けプランなら、会社の保管庫で共有の範囲を会社が決められます。退職時にパスワードを変える作業は残ります。
- [ChatGPT などの生成 AI のアカウントを社内で共有してよいか](https://www.junify.jp/guides/shared-accounts/sharing-chatgpt-accounts-at-work.md): 個人向けの ChatGPT は、利用規約でログイン情報を他人と共有することを禁じています。法人向けの契約も 1 つのアカウントは 1 人だけが使う前提です。複数人で使うなら、法人向けプランで人数分のアカウントを配ります。
- [ブラウザーのパスワード保存を業務で使ってよいか](https://www.junify.jp/guides/shared-accounts/browser-saved-passwords-at-work.md): 個人アカウントのパスワードを、会社が管理するブラウザーの設定で、1 人が使う端末に限って保存するなら選択肢になります。共有アカウント、私物端末、個人アカウントへの同期が絡む場合は避けます。管理者の設定で保存を止められます。
- [共有アカウントを複数人で安全に使う方法の比較](https://www.junify.jp/guides/shared-accounts/comparison-of-shared-account-methods.md): 手作業、パスワードマネージャーの共有、ID 管理サービスによる代わりの入力、アクセス管理ツールの 4 つを、パスワードを知るか、記録の単位、退職時、二段階認証、ログイン後の管理、前提、向く規模の 7 つで比べます。
- [退職者が出るたびにパスワードを変える運用の限界](https://www.junify.jp/guides/shared-accounts/password-change-on-every-departure.md): 一度知られたパスワードは取り消せないため、退職のたびに変える運用には理由があります。限界は、変更後の配り直しと保存先の更新にかかる手間と、誰が知っているかの一覧がないまま起きる抜け漏れです。
- [パスワード管理規程のテンプレートと書き方](https://www.junify.jp/guides/shared-accounts/password-policy-template.md): 規程に入れる項目は、適用範囲、パスワードの条件、保管、共有の禁止と例外、共有アカウント、二段階認証、変更、退職時の手続き、違反時の扱い、見直しの 10 項目です。各条を IPA と個人情報保護委員会の要求に対応づけ、文例を示します。
- [パスワードの定期変更はもう不要か(NIST SP 800-63B の考え方)](https://www.junify.jp/guides/shared-accounts/periodic-password-change.md): NIST SP 800-63B は、サービス側が利用者に定期変更を求めないよう定め、変更を必須にするのは盗まれた証拠があるときとしています。複数人で使う共有アカウントは、知っている人が変わるたびに変更が要ります。
- [共有アカウントの棚卸しの手順と台帳の項目](https://www.junify.jp/guides/shared-accounts/shared-account-inventory.md): 共有アカウントの棚卸しは、サービスごとに誰がパスワードを知っていて誰が使えるかを一覧にする作業です。見つけ方、台帳の項目、分ける・残す・廃止するの判定、更新のきっかけを順に示します。
- [共有アカウントの二段階認証を複数人で使うときの問題と選択肢](https://www.junify.jp/guides/shared-accounts/sharing-two-step-verification.md): 共有アカウントの二段階認証は、コードが 1 人のスマホにしか出ないか、登録用の QR コードを配って全員が出せるかのどちらかになります。方式ごとに起きる問題と、不在と退職に備える選択肢を整理します。
- [パスワードをスプレッドシートで管理する会社が最初に直すこと](https://www.junify.jp/guides/shared-accounts/spreadsheet-password-management.md): 最初に直すのは、そのシートを開ける人の範囲です。次に台帳としての項目を整え、最後にパスワードの値だけを別の保管場所へ移します。一覧としてのスプレッドシートは残せます。
- [Slack・メールでパスワードを送るのをやめる方法](https://www.junify.jp/guides/shared-accounts/stop-sending-passwords-in-chat.md): 送ったパスワードは検索で見つかり、転送や書き出しで広がり、端末と退職者のアカウントに残ります。やめるには、先に別の渡し方を用意し、そのうえで本文に書かないルールを決めます。
- [パスワードマネージャーとは](https://www.junify.jp/guides/shared-accounts/what-is-password-manager.md): パスワードマネージャーは、ID とパスワードを他人が読めない形で保管し、ログイン画面に自動で入力するソフトです。共有機能で配布は整いますが、共有した相手はパスワードを使える状態になります。
- [共有アカウントとは](https://www.junify.jp/guides/shared-accounts/what-is-shared-account.md): 共有アカウントとは、1 つのサービスの 1 つの ID とパスワードを複数の人が使う状態です。サービス側の記録には誰が操作したかが残らないため、別の手段で人を特定する必要があります。
- [二段階認証(二要素認証)とは](https://www.junify.jp/guides/shared-accounts/what-is-two-step-verification.md): 二段階認証とは、パスワードに加えて 2 つ目の確認(認証アプリのコード、SMS、セキュリティキーなど)を求めるログイン方式です。本人が持つものを前提にした仕組みなので、共有アカウントで複数人が使うと本人を特定する意味が失われます。
- [共有アカウントを個人アカウントに分けられないケースの整理](https://www.junify.jp/guides/shared-accounts/when-accounts-cannot-be-split.md): 原則は 1 人 1 アカウントです。それでも、サービスがアカウントを 1 つしか持てない、公式アカウントそのもの、管理者アカウントが 1 つ、外部の人に発行できない、といった場合は共有が残ります。残すものに何を求めるかを整理します。
- [運用代行のクライアントアカウント管理](https://www.junify.jp/guides/agency-accounts.md): 預かり方は権限付与・ID とパスワードの共有・アクセス管理ツールの 3 つ。違いは「誰が使ったかが残るか」と「担当交代時に何をするか」に出ます。
- [クライアントのアカウントの扱いを、運用代行会社のセキュリティの文書にどう書くか](https://www.junify.jp/guides/agency-accounts/agency-security-policy-for-clients.md): 誰でも読める基本方針、社内の規程、クライアントごとに渡す説明書の 3 つに分けて書きます。IPA の規程のサンプルは自社で ID を出して消せる前提なので、預かったアカウント向けに書き換え、説明書にはその結果を書きます。
- [Qoo10・au PAY マーケットの店舗管理を代行するときの担当者のアカウント](https://www.junify.jp/guides/agency-accounts/qoo10-au-pay-market-store-access.md): Qoo10 は QSM のサブ ID で担当者の画面を分けられますが、店舗の ID を共有する仕組みです。au PAY マーケットは分け方が公開されていません。両モールの規約が ID の共有を禁じているので、使う前にモールに確かめます。
- [SNS の予約投稿ツールにクライアントのアカウントをつなぐ権限と、担当が外れたときに外すもの](https://www.junify.jp/guides/agency-accounts/sns-scheduling-tools-client-accounts.md): 連携は、つないだ人の媒体上の権限か、媒体が発行する連携用の文字列で成り立ちます。つなぐ操作はクライアント側の権限者に頼み、担当が外れたら、ツールのメンバー・媒体の権限・連携そのものの 3 か所を確かめます。
- [運用代行会社がクライアントとの契約に入れておくアカウントの条項](https://www.junify.jp/guides/agency-accounts/account-clauses-for-service-providers.md): 入れておきたいのは、アカウントの渡し方、使う担当者の範囲、記録と報告、事故のときの通知、終了と交代の手続きの 5 つです。自社だけで守れる約束と、クライアントに動いてもらう約束を分けて書きます。
- [Amazon セラーセントラルのユーザー権限と、運用代行会社への渡し方](https://www.junify.jp/guides/agency-accounts/amazon-seller-central-user-permissions.md): ヘルプはログイン情報を誰とも共有しないよう求めています。大口出品なら、社内の担当者は「従業員の管理」から招待し、運用代行会社はサービスプロバイダーとして承認します。どちらもユーザー権限の画面から外せます。
- [クライアントのアカウントの二段階認証を運用チームで受けるには](https://www.junify.jp/guides/agency-accounts/client-two-step-verification-for-teams.md): 担当者ごとに招待してもらい、各自のアカウントの二段階認証で入る形に切り替えると、コードの受け渡しはなくなります。所有者のログインが残るアカウントは、受け取り先・予備のコード・使った人の記録をクライアントと決めます。
- [カスタマーサポート代行で、クライアントの Zendesk・Freshdesk に入るときのアカウントと権限](https://www.junify.jp/guides/agency-accounts/cs-outsourcing-helpdesk-access.md): オペレーター 1 人ずつ、代行会社が管理するアドレスでエージェントを作ってもらいます。Zendesk・Freshworks の契約は 1 つのログインの共用を認めていません。権限と範囲は受け持つ分に絞り、外れる人はクライアントが停止します。
- [EC 運営代行で、受注データや顧客データの書き出しをどう制限するか](https://www.junify.jp/guides/agency-accounts/ec-order-data-download-control.md): 書き出しの権限は要る担当者にだけ付けます。Shopify は注文と顧客の書き出しを個別に外せます。BASE は書き出しの App をスタッフが使えるか、画面で確かめます。外せない分は、置き場所・削除・記録の決まりで補います。
- [GA4 とタグ マネージャーの権限を代理店・制作会社に渡すとき](https://www.junify.jp/guides/agency-accounts/ga4-gtm-agency-access.md): GA4 はアカウントかプロパティの単位で閲覧者・編集者などの役割を、タグ マネージャーはコンテナ単位で編集・公開などの権限を渡します。管理者は持ち主の会社に残し、契約終了時は両方のユーザー一覧と Google 広告のリンクを確かめます。
- [Google ビジネス プロフィールのオーナーと管理者を、本部・店舗・運用代行会社でどう分けるか](https://www.junify.jp/guides/agency-accounts/google-business-profile-managers.md): 管理者も投稿・クチコミへの返信・営業時間の編集ができ、ユーザーの追加と削除、プロフィールの削除はオーナーだけです。メインのオーナー権限は本人しか譲れないので、本部が持てば、代行会社との契約が終わるときに代行会社の操作を待たずに済みます。
- [運用代行会社の ISMS・P マーク審査で、クライアントから預かったアカウントをどう説明するか](https://www.junify.jp/guides/agency-accounts/isms-pmark-for-agencies.md): 預かったアカウントは、ISMS では適用範囲に含める資産として、P マークでは受託した個人情報がある場所として扱うと読めます。審査では、アカウントの一覧、使える人、使った記録、外した記録、契約の約束を示します。
- [Microsoft 広告を代理店に任せるときの役割の付け方と外し方](https://www.junify.jp/guides/agency-accounts/microsoft-ads-agency-access.md): 担当者を 1 人ずつ招待する形と、クライアントの広告アカウントを代理店のマネージャー アカウントにつなぐ形の 2 つ。運用担当にはキャンペーンか標準を付けます。招待した人は 1 人ずつ削除し、リンクは解除すると代理店の全員が外れます。
- [在宅のオペレーターにクライアントの管理画面を使わせるとき、決めることと確かめること](https://www.junify.jp/guides/agency-accounts/remote-operators-client-admin-access.md): 決めるのは、在宅で扱うアカウント、使う端末、ログインの渡し方、端末に残してよいデータの 4 つです。確かめるのは端末の状態と、誰がいつ入ったかを後で示せるかです。管理画面に直接つなぐ形では、記録は媒体の側にしか残りません。
- [運用代行の作業記録を、クライアントにどう報告するか](https://www.junify.jp/guides/agency-accounts/reporting-work-records-to-clients.md): 媒体の操作履歴から日時・担当者・操作を抜き出して報告に添えます。媒体の履歴で担当者まで分からない共有 ID のアカウントは社内の作業記録で補い、各行がどちらに基づくかを書き分けます。
- [Yahoo!広告(現 LINEヤフー広告)を代理店や複数人で運用するときの権限付与](https://www.junify.jp/guides/agency-accounts/yahoo-ads-agency-access.md): 管理権限を持つ人が担当者のビジネス ID を招待し、管理・登録更新・参照の 3 種類から権限を選びます。代理店の MCC につないで任せる形もあります。どちらの形でもパスワードは渡さず、外すときは権限の削除かリンクの解除です。
- [YouTube チャンネルを社内の複数人や運用代行会社と運用するときの権限](https://www.junify.jp/guides/agency-accounts/youtube-channel-permissions.md): YouTube Studio の「チャンネルの権限」で、担当者のメールアドレスごとに管理者・編集者・閲覧者などの役割を付けて招待すれば、Google アカウントのパスワードを渡さずに任せられます。外すときは同じ画面でアクセス権を削除します。
- [クライアントのセキュリティチェックシートへの、運用代行会社の答え方](https://www.junify.jp/guides/agency-accounts/answering-security-questionnaires.md): 設問は個人情報保護委員会ガイドライン(通則編)別添の安全管理措置の項目に対応しています。現状をそのまま書き、共有 ID は管理方法まで書き、対応予定には期限と担当を添えます。
- [楽天 RMS・Yahoo! ショッピングの店舗管理を代行するときのアカウント](https://www.junify.jp/guides/agency-accounts/ec-mall-store-admin-access.md): 楽天は担当者ごとの楽天 ID を店舗の管理者が承認し、Yahoo! はビジネスマネージャーでツール管理者が従業員のビジネス ID を登録します。どちらも担当者ごとに ID を持つ仕組みです。
- [「御社にアカウントを預けて大丈夫か」に商談で答えるための説明の型](https://www.junify.jp/guides/agency-accounts/explaining-account-handling-in-sales.md): 預かり方(権限付与・共有・アクセス管理ツール)ごとに、担当者はパスワードを知るか、誰が使ったかは残るか、担当交代で何が起きるか、の 3 問に答えます。根拠は預かっているアカウントの一覧に置きます。
- [Google 広告の MCC(クライアント センター)で代理店アクセスを整理する](https://www.junify.jp/guides/agency-accounts/google-ads-mcc-agency-access.md): クライアントのアカウントを MCC にリンクし、担当者は MCC のユーザーとして招待します。担当交代は MCC 側でその人のアクセス権を削除すれば済み、クライアントのパスワードは受け取りません。
- [運用担当者の交代・退職時のアカウント引き継ぎチェックリスト](https://www.junify.jp/guides/agency-accounts/handover-checklist.md): 交代前に担当アカウントの一覧・二段階認証のコードの受け取り先・共有 ID を確かめます。当日は招待の取り消し・パスワード変更の依頼・ツール上での利用停止とクライアントへの連絡を行い、後日に反映を確かめて一覧を更新します。
- [LINE 公式アカウントを複数人・外部と運用するときの権限](https://www.junify.jp/guides/agency-accounts/line-official-account-permissions.md): 管理者が発行する認証用 URL で担当者ごとにメンバーを追加し、管理者か運用担当者の権限を持たせます。外部の運用代行会社も同じ形で追加でき、外すときはメンバーのリストから削除します。
- [Meta(Facebook・Instagram)のビジネスポートフォリオで代理店に権限を付与する仕組みと、できないこと](https://www.junify.jp/guides/agency-accounts/meta-business-portfolio-agency-access.md): クライアントのポートフォリオに担当者を「人」として招くか、代理店のポートフォリオを「パートナー」としてつなぎます。ページ・広告アカウント・Instagram ごとに、許す操作(タスク)を付けます。取り消しは所有者側の操作です。
- [Shopify・BASE などカート側のスタッフ権限と、運用代行会社への渡し方](https://www.junify.jp/guides/agency-accounts/shopify-base-staff-permissions.md): Shopify はスタッフの招待か、パートナー向けのコラボレーターアカウントで渡します。BASE は「スタッフ権限管理 App」でスタッフごとにメニュー単位の権限を付けられます。どちらもオーナーの ID は渡しません。
- [誤投稿・誤設定のあとに原因を追える運用と追えない運用](https://www.junify.jp/guides/agency-accounts/tracing-misposts.md): 報告に要るのは「誰が・いつ・何を」の 3 つです。共有 ID では媒体の記録が ID 単位で担当者まで絞れず、権限付与かアクセス管理ツールなら人単位で残ります。記録がなければ作業記録から推定するほかありません。
- [運用代行におけるアカウントの預かりとは](https://www.junify.jp/guides/agency-accounts/what-is-delegated-account-access.md): クライアントが所有する SNS・広告・EC のアカウントを、運用代行会社の担当者が業務のために操作できる状態にすること。委任の範囲とアカウントの扱いは別の問題です。
- [権限付与(アカウントを共有しないアクセス)とは](https://www.junify.jp/guides/agency-accounts/what-is-delegated-permission.md): アカウントの所有者が、パスワードを渡さずに他の人に操作を許可する仕組み。権限の種類・招待・取り消しの 3 つで成り立ち、誰が操作したかが人ごとに残ります(媒体が履歴を残す範囲で)。
- [X・TikTok の企業アカウントを運用代行するときの権限と共有 ID](https://www.junify.jp/guides/agency-accounts/x-tiktok-business-account-access.md): X は広告アカウントの権限(ロール)と、投稿や DM を任せる委任機能(X アカウント権限の付与)を別々に付けます。TikTok はビジネスセンターにメンバーかパートナーとして招きます。どちらもパスワードは渡しません。
- [委託先に自社のアカウントを使わせるときの管理](https://www.junify.jp/guides/outsourcing-access.md): 個人情報保護法が委託元に求めるのは委託先の監督で、アカウントの渡し方までは指定していません。渡し方は 3 つあり、違いは誰が使ったかの記録と、契約終了時の作業に出ます。
- [委託終了・担当交代時のアクセス回収チェックリスト](https://www.junify.jp/guides/outsourcing-access/access-recovery-at-contract-end.md): 順番は、委託先が使っている自社アカウントの一覧 → 発行したユーザーの停止 → 共有アカウントのパスワード変更 → 記録の確認 → 返却・消去の確認です。担当交代なら、その人の分だけを同じ順で行います。
- [委託先へのセキュリティチェックシートの作り方(アカウント管理の設問)](https://www.junify.jp/guides/outsourcing-access/building-a-security-questionnaire.md): 設問は、自社が渡したアカウントを名指しし、誰が・いつ・何で確かめているかを書いてもらう形にします。10 問を別添の項目に対応づけ、答えは自社の記録と現地や口頭の確認で突き合わせます。
- [委託契約に入れるアカウント条項(貸与・共有禁止・記録・返却)の要点](https://www.junify.jp/guides/outsourcing-access/contract-clauses-for-accounts.md): ガイドラインが契約に盛り込むことが望ましいとするのは、合意した安全管理措置の内容と、取扱状況を委託元が把握できることです。アカウントの条項は、貸与の範囲・共有の禁止・記録の提出・終了時の返却の 4 つに分けて書きます。
- [ISMS(ISO/IEC 27001:2022)の供給者関係の管理とアカウント共有](https://www.junify.jp/guides/outsourcing-access/isms-supplier-relationships.md): JIS Q 27002:2024 の目次では、5.19〜5.22 が供給者関係の管理策で、5.23 がクラウドサービスの利用です。委託先に自社のアカウントを使わせる場面は、この管理策と通則編の選定・契約・把握を対応づけて読めます。
- [委託先経由の情報漏えいで問われる責任(公開事例から)](https://www.junify.jp/guides/outsourcing-access/liability-in-contractor-breaches.md): 個人情報保護委員会の公表では、委託先で起きた漏えいでも、委託元が 25 条の委託先の監督の不備を指導されています(1 件は自社の安全管理措置の不備で勧告も)。問われたのは、確認の取り決めがない契約、監査や点検の不実施、再委託の未報告です。
- [副業人材・フリーランス・パートに社内アカウントを渡すときの線引き](https://www.junify.jp/guides/outsourcing-access/side-jobs-freelancers-part-timers.md): パート・アルバイト・派遣社員はガイドラインの「従業者」に含まれ、従業者の監督(24 条)の対象です。業務委託のフリーランスは委託先で、委託先の監督(25 条)の側です。副業人材は、自社との契約が雇用か業務委託かで分かれます。
- [再委託先のアクセスをどう把握するか](https://www.junify.jp/guides/outsourcing-access/subcontractor-access-visibility.md): 把握は 3 つの決まりで成り立ちます。再委託の事前報告に、再委託先の人が使う自社のアカウントを含めること。再委託先の人にも一人ずつ発行すること。自社のユーザー一覧と報告された名簿を定期的に突き合わせることです。
- [セキュリティチェックシートとは(委託元の側)](https://www.junify.jp/guides/outsourcing-access/what-is-security-questionnaire.md): 委託元が、委託先の安全管理措置(個人データを守る対策)を書面で確かめる質問票。ガイドラインが委託前に求める確認の手段の一つと読めます。設問は別添の項目に沿って作ります。
- [再委託とは](https://www.junify.jp/guides/outsourcing-access/what-is-subcontracting.md): 委託先が、受けた業務の全部または一部をさらに別の者に任せること。ガイドラインは、委託元が事前に報告を受けるか承認し、再委託先の安全管理措置まで確かめることが望ましいとしています。
- [委託先の監督とは](https://www.junify.jp/guides/outsourcing-access/what-is-supervision-of-contractors.md): 個人データの取扱いを委託する事業者が、委託先でも安全管理措置(個人データを守る対策)が行われるよう確かめること(個人情報保護法 25 条)。ガイドラインは選定・契約・取扱状況の把握の 3 点を挙げています。
- [委託先が「共有 ID で作業しています」と答えたときの確認事項](https://www.junify.jp/guides/outsourcing-access/when-contractor-uses-shared-id.md): 確かめるのは 4 点です。対象のアカウント、パスワードを知っている人の範囲、担当交代時の変更手順、誰がいつ使ったかを残す方法です。答えられなければ、担当者ごとの発行に切り替える、アクセス管理ツールを挟む、業務範囲を絞る、のどれかを選びます。
- [管理者用アカウント(特権 ID)の管理](https://www.junify.jp/guides/privileged-access.md): 管理者用アカウント(特権 ID)は、サービスの設定や他の人の権限を変えられる強い権限の ID です。個人に分けられる権限は分け、残る共有の管理者アカウントは誰が使ったかを残せる形にします。
- [AWS のルートユーザー・管理者アカウントを複数人で使うときの管理](https://www.junify.jp/guides/privileged-access/aws-root-and-admin-accounts.md): AWS は、ルートユーザーを日常の作業に使わず、それにしかできない作業に限るよう勧めています。日常の管理は IAM Identity Center の個人の ID で行い、ルートユーザーは二段階認証(MFA)を付けて保管し、記録を残します。
- [SaaS の管理者用アカウントを管理する方法の比較](https://www.junify.jp/guides/privileged-access/comparison-of-privileged-account-methods.md): 台帳と貸出の記録、ID 管理サービスの代わりの入力、特権 ID 管理(PAM)の製品、アクセス管理ツールの 4 つを、パスワードを知るか、記録の単位、退職時、二段階認証、ログイン後の管理、前提、向く規模の 7 つで比べます。
- [Google Workspace・Microsoft 365 の特権管理者アカウントの管理](https://www.junify.jp/guides/privileged-access/google-workspace-microsoft-365-admins.md): 最上位の管理者(特権管理者・グローバル管理者)を少なくし、役割に応じた管理者権限に分け、管理者に二段階認証を必須にし、緊急用のアカウントを分けます。Google と Microsoft の公式ドキュメントが勧めることの整理です。
- [Okta・Entra ID がある会社で、それでも残る共有の管理者アカウント](https://www.junify.jp/guides/privileged-access/idp-and-remaining-shared-admins.md): ID 管理サービスは、共有の管理者アカウントも預かったパスワードを代わりに入力する機能で扱えます。残るのは、そこにアカウントのない人が使う場面、ログイン後の記録が要る場面、管理画面側の二段階認証のコードを扱う場面の 3 つです。
- [IT 全般統制(J-SOX)で管理者用アカウントについて問われること](https://www.junify.jp/guides/privileged-access/itgc-and-privileged-ids.md): 実施基準は「内外からのアクセス管理」を IT 全般統制の例に挙げ、評価は記録の閲覧や質問で行われます。用意するのは、管理者用アカウントの一覧、権限の付与・変更・削除の記録、利用の記録、定期的な見直しの記録です。
- [ドメイン・DNS・決済など ID 管理サービスとつなげない管理画面の ID をどう扱うか](https://www.junify.jp/guides/privileged-access/non-saml-admin-consoles.md): まず公式ヘルプで、担当者ごとの ID を追加できるか、権限を分けられるかを確かめます。追加できるなら個人の ID にし、1 つしか作れないものは共有として貸出の記録、二段階認証の宛先、パスワードを変える場面を決めます。
- [管理者用アカウントの監査で示せるようにしておく記録](https://www.junify.jp/guides/privileged-access/privileged-access-audit-records.md): 公的な資料が求めるのは、誰が・いつ・どのアカウントで・何をしたかがつながる記録と、権限の付与・削除と見直しの記録です。金融庁、内閣官房、IPA の 4 つの文書は、改ざんの防止と定期的な点検も共通して求めています。
- [緊急用アカウント(ブレークグラス)とは](https://www.junify.jp/guides/privileged-access/what-is-break-glass-account.md): 緊急用アカウントとは、普段の管理者アカウントが使えなくなったときのために置いておく、強い権限を持つ予備のアカウントです。普段は使わず、使ったら記録を確かめて見直します。
- [特権 ID 管理(PAM)とは](https://www.junify.jp/guides/privileged-access/what-is-pam.md): 特権 ID 管理(PAM)とは、管理者用アカウントの利用申請と承認、権限の付与、操作の記録を仕組みで行う管理の方法です。IPA は、特権の利用申請や権限付与、操作ログなどを管理する技術と説明しています。
- [特権 ID(管理者用アカウント)とは](https://www.junify.jp/guides/privileged-access/what-is-privileged-id.md): 特権 ID とは、コンピューターやサービスを管理するための最上位の権限を持つ ID です。サーバーの管理者だけでなく、クラウドや SaaS の管理者アカウント、ドメインや決済の管理画面の ID も含みます。
- [医療・ヘルスケアのアカウント管理](https://www.junify.jp/guides/healthcare-access.md): 医療機関のアカウント管理で決めることは、使う人を確かめる方法、権限の付け方と外し方、誰が何をしたかの記録の 3 つです。水準は厚労省のガイドライン第 7.0 版が示しています。
- [予約・問診・オンライン診療などのクラウドサービスで、アカウント管理の責任はどこで分かれるか](https://www.junify.jp/guides/healthcare-access/clinic-saas-responsibility-split.md): 基本の形は、サービス側の仕組みと安全対策は事業者、誰に ID を出していつ止めるかは医療機関です。厚労省のガイドライン第 7.0 版は、この分かれ目を事業者と文書で取り決め、開示書(MDS/SDS)で確かめるよう求めています。
- [医療機関がサイバー攻撃を受けたとき、アカウントについて最初に行うこと](https://www.junify.jp/guides/healthcare-access/medical-cyber-incident-account-response.md): 初動は保守会社への連絡、ネットワークの遮断と攻撃者が残した裏口の無効化、記録の保全です。侵害された可能性のある機器の ID とパスワードの無効化は、ガイドラインでは復旧の際の方策です。非常時用のアカウントは正常に戻った後に使えなくします。
- [オンライン資格確認の端末で使うアカウントとパスワードの管理](https://www.junify.jp/guides/healthcare-access/online-eligibility-verification-terminal.md): 資格確認端末には Windows のログイン、電子証明書、システムのアカウントがあり、顔認証付きカードリーダーにもアカウントがあります。システムのアカウントは職員一人ずつ作って退職時に止め、管理用の ID は持つ人と保管場所を決めます。
- [医療機関で職員が退職・異動したとき、どのアカウントを、いつ、誰が止めるか](https://www.junify.jp/guides/healthcare-access/staff-departure-account-shutdown.md): 止めるのは、その人が使える医療情報システムの ID すべてで、院外のクラウドサービスも含みます。複数人で使う ID はパスワードを変えます。厚労省のガイドラインに日数の定めはないので期限は施設で決め、止めるのはシステムの担当者か事業者です。
- [医療法に基づく立入検査で、サイバーセキュリティについて確認されること](https://www.junify.jp/guides/healthcare-access/medical-onsite-inspection-cybersecurity.md): 病院への立入検査は原則年 1 回です。サイバーセキュリティでは、厚労省のチェックリストの全項目に確認日と回答が書かれているかを見て、機器の台帳・連絡体制図・BCP・規程類は現物を確かめます。
- [厚労省のサイバーセキュリティ対策チェックリスト(令和 8 年度版)で、アカウントとアクセスの項目をどう確かめるか](https://www.junify.jp/guides/healthcare-access/mhlw-cybersecurity-checklist-accounts.md): 区分 2 の 7 項目(権限、不要なアカウント、パスワード 2 項目、二要素認証 2 項目、アクセスの記録)です。台帳を在籍者の一覧と照らし、記録を確かめた跡を残し、事業者が「対象外」とした項目は院内の担当を決めます。
- [医療情報システムの安全管理に関するガイドラインが定めるパスワードの桁数・変更・使い回し](https://www.junify.jp/guides/healthcare-access/password-rules-in-medical-guideline.md): 現行の第 7.0 版では、二要素認証を使うならパスワードは 8 桁以上で英数字を混ぜ、使わないなら 13 桁以上です。定期的な変更はどちらも不要で、システム間で使い回さないことは遵守事項です。
- [薬局・介護事業所のシステム(電子薬歴・介護記録・請求ソフト)のアカウント管理](https://www.junify.jp/guides/healthcare-access/pharmacy-care-facility-accounts.md): 薬局も介護事業者も厚労省の医療情報ガイドラインの対象です。職員ごとの ID、業務に合う権限、辞めた人の ID の停止、使った人の記録が求められます。1 つしか届かない介護の請求用 ID は、知る人と使った記録を事業所で決めます。
- [電子カルテなどからの患者データの持ち出しを防ぎ、記録する方法](https://www.junify.jp/guides/healthcare-access/preventing-patient-data-exfiltration.md): 厚労省のガイドライン第 7.0 版は、持ち出す情報と方法を規程で決め、媒体と院外からのネットワーク経由の両方を想定するよう求めます。見る権限と使えるサービスを仕組みで絞り、持ち出しの承認・媒体の台帳・アクセスの記録を残して見直します。
- [医療情報システムの遠隔保守(リモートメンテナンス)で、保守事業者のアクセスをどう管理するか](https://www.junify.jp/guides/healthcare-access/remote-maintenance-vendor-access.md): 管理の責任は医療機関に残ります。厚労省のガイドライン第 7.0 版は、保守要員に専用のアカウントを使わせ、遠隔保守では必ず記録を集めて作業計画書と照合することを求めます。つながる経路の一覧と契約も要ります。
- [私物端末(BYOD)から診療システムを使うときの安全管理](https://www.junify.jp/guides/healthcare-access/byod-for-clinical-systems.md): 厚労省のガイドラインは私物端末の利用を禁じていませんが、許可の条件・利用範囲・管理方法などを規程に書いて台帳で管理し、院内の端末と同等の対策を手順にすることを求めます。管理されていない端末での利用は許可してはならないとしています。
- [医療機関のアクセスの記録(監査ログ)は何をどこまで残す必要があるか](https://www.junify.jp/guides/healthcare-access/medical-audit-log-retention.md): 遵守事項は、ログイン時刻・アクセス時間・操作した医療情報が分かる記録を残して定期的に確かめ、改ざんを防ぎ、時刻を正確に保つことです。年数の定めは厚労省のガイドラインになく、2 省ガイドラインが法定保存年限以上を原則にしています。
- [厚労省ガイドライン(第 7.0 版)が求める認証・アクセス管理を自施設に当てはめる](https://www.junify.jp/guides/healthcare-access/mhlw-guideline-authentication-and-access-control.md): 求められるのは、利用者ごとの識別・認証、ID とパスワードを本人しか知り得ない状態に保つこと、申請に基づく権限付与、二要素認証、ID の台帳と棚卸しです。遵守事項ごとに、施設で確かめる点を表にします。
- [オンライン診療で入れ替わる医師・スタッフのアカウント管理](https://www.junify.jp/guides/healthcare-access/online-clinic-staff-turnover-accounts.md): 指針は、医療機関に多要素認証を用いるのが望ましいとし、事業者にアクセス権限の管理、退職者アカウントの削除の重点的な監視、アクセスログの保全を求めます。医師が交代する施設は、診療計画の医師名と ID の一覧を合わせます。
- [医事業務・レセプト業務を委託するときのアカウント](https://www.junify.jp/guides/healthcare-access/outsourcing-medical-billing-accounts.md): 企画管理編 7 章の遵守事項は、委託契約の契約書に守秘・非開示を含め、委託先の就業規則等にも同じ対応を求めることです。ID は外部の利用者として、要員ごとにアクセス権限とアクセス状況を管理できる形で用意します。
- [電子カルテ・診療システムの ID を複数人で使うことの問題と現実](https://www.junify.jp/guides/healthcare-access/sharing-ehr-accounts-among-staff.md): 厚労省のガイドラインの遵守事項は、ID とパスワードを本人しか知り得ない状態に保つことです。考え方の節は、全ての職員と関係者に本人の ID 等を用意するとしています。共有 ID はどちらにも載りません。
- [医療機関の二要素認証で求められることと、共有アカウントで起きること](https://www.junify.jp/guides/healthcare-access/two-factor-authentication-with-shared-accounts.md): 医療情報システムを新規に入れるときや入れ替えるとき、二要素認証の採用が遵守事項です。共有アカウントに付けても、コードは 1 人の端末に届き、誰が使ったかは残りません。
- [3 省 2 ガイドラインとは](https://www.junify.jp/guides/healthcare-access/what-is-3-ministries-2-guidelines.md): 3 省 2 ガイドラインとは、厚労省の医療機関等向けガイドラインと、総務省・経産省の事業者向けガイドラインを合わせた通称です。医療情報を扱う側と、そのシステムを提供する側の 2 本で 1 組です。
- [医療情報システムの安全管理に関するガイドラインとは](https://www.junify.jp/guides/healthcare-access/what-is-medical-information-system-security-guideline.md): 厚労省が医療機関等に向けて定める、医療情報システムの安全管理の指針です。現行は第 7.0 版(令和 8 年 6 月)で、経営層・企画管理者・運用担当者ごとの編に分かれ、認証や記録の遵守事項を示します。
- [人事・採用のアカウント管理](https://www.junify.jp/guides/hr-access.md): 採用媒体や人事・給与システムの企業アカウントは、担当者・応援要員・採用代行で共有されがちです。応募者と従業員の情報は安全管理措置の対象で、使える人の限定、使った人の記録、退職時の停止が問われます。
- [Indeed の企業アカウントを採用代行や社内の複数人で使うときのユーザー管理](https://www.junify.jp/guides/hr-access/indeed-employer-account-with-rpo.md): Indeed の利用規約はログイン情報の共有を認めていないので、使う人を一人ずつユーザーとして追加します。追加と削除は管理者が「登録ユーザー」で行い、権限は役割か、権限の組み合わせ(カスタム)で付けます。削除は本人に通知されません。
- [採用代行(RPO)に媒体アカウントを渡すときの整理](https://www.junify.jp/guides/hr-access/handing-job-board-accounts-to-rpo.md): 渡し方は 3 つです。媒体の委託先向けの手続きを使う、委託先の担当者に ID を発行する、共有 ID を渡す。応募者情報を扱わせるなら個人情報保護法 25 条の委託先の監督が要り、契約、記録、終了時の回収を決めます。
- [人事システム・給与システムの共有 ID の問題](https://www.junify.jp/guides/hr-access/hr-payroll-system-shared-ids.md): 給与・マイナンバー・評価を扱うシステムの管理者アカウントを共有すると、個人情報保護法と番号法が求める使う人の識別と認証、利用の記録、担当者の明確化を ID の単位で満たせず、内部統制でも誰が操作したかを示せません。
- [採用媒体のアカウントを複数人で使うときの権限と共有 ID](https://www.junify.jp/guides/hr-access/job-board-account-roles-and-shared-ids.md): 担当者ごとの ID を発行できるかは媒体で分かれます。発行できる媒体には権限の種類があり、1 つの ID を全員で使う媒体もあります。退職時に何を操作するかも媒体ごとに違います。
- [入社・退職時のアカウント管理チェックリスト](https://www.junify.jp/guides/hr-access/onboarding-offboarding-checklist.md): 入社時は本人ごとの ID・必要な範囲の権限・共有アカウントの利用許可・誓約書、退職時は ID の停止・共有パスワードの変更・情報と機器の回収・実行の記録です。期限の一例は、退職の翌日までです。
- [応募者情報の持ち出しを防ぐアクセス管理](https://www.junify.jp/guides/hr-access/preventing-applicant-data-exfiltration.md): 応募者情報は個人情報保護法の安全管理措置と職業安定法 5 条の 5 の対象です。見られる人を採用に関わる人に限り、媒体からの出力・履歴書の保存先・面接官への共有・私物端末の 4 つの経路に制限と記録を置きます。
- [採用の繁忙期に増える人へ、パスワードを渡さずに媒体を使わせる方法](https://www.junify.jp/guides/hr-access/seasonal-hiring-staff-without-sharing-passwords.md): 方法は 4 つです。媒体で本人の ID を追加する、ID 管理サービスに預ける、パスワードマネージャーで共有する、パスワードを見せずに代わりに入力する。このうち 3 つは、教えずに済みます。
- [オンボーディング・オフボーディング(アカウントの観点)とは](https://www.junify.jp/guides/hr-access/what-is-onboarding-offboarding.md): アカウントの観点では、オンボーディングは入社・応援の開始に合わせて本人の ID と権限を発行し、共有アカウントを使える人に加えること。オフボーディングは退職・終了に合わせてそれらを止め、共有のパスワードを変えることです。
- [SaaS のログインを会社が管理する方法の全体像](https://www.junify.jp/guides/access-basics.md): SaaS のログインを会社が管理する方法は、ID 管理サービスによる SSO、パスワードマネージャー、特権 ID 管理、管理されたブラウザー、代わりに入力する仕組みなどに分かれ、アカウントの種類ごとに組み合わせます。
- [私物端末に残る業務の情報と、残さずにウェブサービスを使わせる方法](https://www.junify.jp/guides/access-basics/byod-leave-no-business-data.md): 主に残るのは閲覧履歴、クッキー、保存したパスワード、パスワードマネージャーの写し、ダウンロードしたファイルです。閉じると履歴を消すウィンドウでもファイルは残ります。会社が配るブラウザーの設定と、パスワードを本人に渡さない形を組み合わせます。
- [業務の画面操作を記録する仕組みは、何を基準に選ぶか](https://www.junify.jp/guides/access-basics/choosing-session-recording.md): 先に、記録を何に使うか(顧客への報告、事故の調べ、監査)を決めます。そのうえで、記録する範囲、映像か操作の文字か、保存期間と見られる人、本人への知らせ方、容量と費用を、その使い道に合わせて確かめます。
- [Microsoft Entra ID と Junify の違い、パスワードベース SSO で共有アカウントを使わせるときの使い分け](https://www.junify.jp/guides/access-basics/entra-id-and-junify.md): 共有アカウントを使う人が全員 Entra ID のアカウント(社外の人はゲスト)を持ち、ログイン後の管理が要らないなら Entra ID のパスワードベース SSO で足ります。そうでない分は Junify が補います。
- [HENNGE One と Junify の違い、SSO のないサービスと共有アカウントの管理での使い分け](https://www.junify.jp/guides/access-basics/henngeone-and-junify.md): 全員が HENNGE One の ID を持ち、SSO のないサービスも一人ずつの ID で足りるならそれで済みます。ID のない人と使う共有アカウントや、ログイン後のダウンロードと録画まで管理したい分を Junify が補います。
- [Okta と Junify の違い、SWA で共有アカウントを使う場合との使い分け](https://www.junify.jp/guides/access-basics/okta-and-junify.md): 使う人が全員 Okta の ID を持ち、ログイン後の操作まで管理しないなら、SWA を含めて Okta で足ります。Okta に ID のない人と使う共有アカウントや、ログイン後のダウンロードと録画の管理を Junify が補います。
- [仮想デスクトップ(VDI)をやめて、ブラウザーだけで済ませられる業務](https://www.junify.jp/guides/access-basics/replacing-vdi-for-web-work.md): ブラウザーだけで済ませやすいのは、使うものがすべてウェブのサービスで、ファイルを手元で開かない業務です。ファイルを手元のソフトで開く業務は残るファイルの扱いを決めてから移し、パソコンに入れるアプリが要る業務は仮想デスクトップに残します。
- [SaaS のファイルのダウンロードを禁止・制限する方法](https://www.junify.jp/guides/access-basics/saas-download-restriction.md): 止める場所は 3 つです。サービスの権限で止める、会社が管理していない端末からのときだけ止める、ブラウザーの設定で止める。どれでも止められない分は、書き出してよい人と置き場所を決め、記録で補います。
- [ID 管理サービスで退職者を止めた後も SaaS に残るログイン状態](https://www.junify.jp/guides/access-basics/saas-sessions-after-offboarding.md): 残ることがあります。止める操作で終わるのは ID 管理サービス自身のログインと次からのログインです。各 SaaS が発行したログイン状態は、その SaaS の期限か SaaS 側での取り消しまで続きます(対応した一部のサービスを除く)。
- [GMO トラスト・ログインと Junify の違い、共有アカウントの管理での使い分け](https://www.junify.jp/guides/access-basics/trustlogin-and-junify.md): 全員がトラスト・ログインの ID を持ち、SSO とパスワードの自動入力で足りるならそれで済みます。ブラウザーにパスワードを残したくない共有アカウント、メールアドレスのない人が使う分、ログイン後も管理したい分を Junify が補います。
- [セキュアブラウザとは](https://www.junify.jp/guides/access-basics/what-is-secure-browser.md): セキュアブラウザとは、業務のウェブサービスを使うときに、ダウンロードや印刷などを会社が制限できるブラウザーです。専用のブラウザーを入れる製品のほか、普段のブラウザーに会社の設定や拡張機能を足す製品もあります。
- [監査ログと、監査で示す記録の違い](https://www.junify.jp/guides/access-basics/audit-log-vs-evidence.md): 監査ログは、システムが動作や利用のたびに自動で残す記録です。監査で示す記録は、そこから誰が・いつ・何をしたかを説明できるように選び、改ざんを防いで決めた期間保存し、管理者以外が点検したものを指します。
- [ブラウザーの拡張機能でできるアクセス管理の範囲](https://www.junify.jp/guides/access-basics/browser-extension-access-control-scope.md): 拡張機能は、それを入れたブラウザーの中で、決めたサイトのページを読み取り、入力し、動作を変えられます。ブラウザーの外のアプリと、拡張機能の入っていないブラウザーや端末には届きません。この線引きが選ぶときの基準です。
- [私物端末(BYOD)で業務システムを使わせるときの選択肢](https://www.junify.jp/guides/access-basics/byod-options-mdm-vdi-browser.md): 選択肢は 5 つです。端末全体を管理する MDM、仕事のアプリだけを管理する MAM、画面だけを映す仮想デスクトップ、会社が管理するブラウザー、パスワードを見せずに代わりに入力する仕組み。会社が何を管理するかで分かれます。
- [SaaS のアカウントを管理するツールの種類と違い](https://www.junify.jp/guides/access-basics/comparison-of-access-management-tool-categories.md): ID 管理サービス、パスワードマネージャー、特権 ID 管理(PAM)、Enterprise Browser、SaaS 管理ツール、代わりに入力する仕組みの 6 種類を、何を解くか、対象、記録の単位など 5 点で比べます。
- [最小権限の原則を SaaS の共有アカウントに当てはめる](https://www.junify.jp/guides/access-basics/least-privilege-for-shared-saas-accounts.md): 共有アカウントでは権限が ID に付き、使う人全員に同じ権限が渡るため、人ごとには絞れません。まず SaaS 側の権限の種類(閲覧・編集・管理者)で個人に分け、共有が残る部分は、使える人の一覧、期間、記録の 3 つで補います。
- [QR コードでログインする方式と、フィッシングへの強さ](https://www.junify.jp/guides/access-basics/qr-code-login-and-phishing-resistance.md): QR コードでログインする方式は、パソコンの画面の QR をログイン済みのスマホで読み、スマホ側で承認する仕組みです。パスワードを打たない分だけ盗まれにくく、他人が表示させた QR を承認すると入られる弱さがあります。
- [SAML に対応していない SaaS に SSO に近い運用を作る方法](https://www.junify.jp/guides/access-basics/sso-like-operation-for-non-saml-saas.md): SAML などに対応しない SaaS でも、ID 管理サービスの代理入力、パスワードマネージャーの共有、代わりに入力する仕組みで SSO に近い形にできます。違いは担当者がパスワードを知るかと記録の単位です。
- [IdP(ID 管理サービス)とは](https://www.junify.jp/guides/access-basics/what-is-idp.md): IdP(ID 管理サービス)とは、社員の ID を一か所で保ち、ログイン時の本人確認を引き受け、つながるサービスに使ってよい人を決める仕組みです。Okta や Microsoft Entra ID が代表です。
- [最小権限の原則とは](https://www.junify.jp/guides/access-basics/what-is-least-privilege.md): 最小権限の原則とは、人やプログラムに与える権限を、その仕事に必要な最小限にとどめる考え方です。NIST が設計の原則として定義し、IPA も ID の割り当てを必要最小限にするよう勧めています。
- [多要素認証(MFA)とは](https://www.junify.jp/guides/access-basics/what-is-mfa.md): 多要素認証とは、知っているもの(パスワード)、持っているもの(スマホや IC カード)、本人自身(指紋や顔)の 3 種類のうち 2 つ以上でログイン時に本人を確かめる方式です。パスワードが漏れてもすぐには入られないようにします。
- [パスワードレスとは](https://www.junify.jp/guides/access-basics/what-is-passwordless.md): パスワードレスとは、パスワードの代わりに端末の中の鍵などで本人を確かめるログイン方式です。パスキー(FIDO)が代表です。パスワードを見せずに代わりに入力する方式は、パスワードが残るので別の仕組みです。
- [セッション録画(画面操作の記録)とは](https://www.junify.jp/guides/access-basics/what-is-session-recording.md): セッション録画とは、ログインしてから終えるまでの利用を、画面の映像や入力した文字として残す仕組みです。何が残り何が残らないかは製品ごとに違い、本人への明示も要ります。
- [SSO(シングルサインオン)とは](https://www.junify.jp/guides/access-basics/what-is-sso.md): SSO(シングルサインオン)とは、一度ログインすれば、使ってよい複数のサービスにログインし直さずに入れる仕組みです。ID 管理サービスと SAML などの規格でつながるサービスにだけ使え、つながらないサービスには別の方法が要ります。
- [ゼロトラストとは](https://www.junify.jp/guides/access-basics/what-is-zero-trust.md): ゼロトラストとは、社内ネットワークにいるからといって信頼せず、利用のたびに利用者と端末を確かめてから最小限のアクセスを許す考え方です。NIST SP 800-207 が定義し、総務省は「決して信頼せず、必ず確認せよ」と言い表しています。
- [法令・ガイドラインとアカウント管理](https://www.junify.jp/guides/compliance.md): 法令や公的な指針がアカウントの管理に求めることは、誰が使ったか分かる・権限は必要最小限・退職や契約終了で止める・委託先を確かめる、の 4 点にまとまります。
- [CIS Controls v8.1 の Control 5(アカウント管理)と Control 6(アクセス制御管理)は何を求めるか](https://www.junify.jp/guides/compliance/cis-controls-account-access-management.md): Control 5 は全アカウントの一覧、使われていないアカウントの停止、管理者専用アカウントを求めます。Control 6 は権限を与える・外す手順と、社外向けサービスと管理者の多要素認証を求めます。どれも IG1(最初の段階)です。
- [漏えい等の報告で、アクセスの記録(ログ)から示すこと](https://www.junify.jp/guides/compliance/data-breach-report-access-logs.md): 報告の 9 項目のうち、アクセスの記録で裏づけるのは概要の経過、個人データの項目、本人の数、原因の 4 つです。見られていないことを記録で確かめられなければ、その範囲は漏えいかそのおそれに当たり得ます。
- [政府の統一基準が求める ID の管理と委託先の対策](https://www.junify.jp/guides/compliance/government-unified-standards-accounts.md): 統一基準は、ID を適切に管理し、不要になれば速やかに止め、権限を必要最小限にするよう求めます。ガイドラインは 1 人 1 つの ID を原則とし、共用は使った人を特定できる仕組みを条件に認めます。委託先には情報を守る対策を契約で求めます。
- [内部監査でアカウントの管理を確かめるときの観点と記録](https://www.junify.jp/guides/compliance/internal-audit-account-checklist.md): 経済産業省のシステム監査基準は、口頭の説明だけに頼らず書類との照合で裏付けるよう求めています。アカウントでは、利用者の一覧を人事の名簿や承認の記録と突き合わせ、退職者の削除、共有 ID の承認、見直し、利用の記録を確かめます。
- [ISMAP の管理基準がクラウドサービス事業者に求めるアカウント管理](https://www.junify.jp/guides/compliance/ismap-account-management.md): ISMAP 管理基準は、事業者のシステムに入る人の ID の登録と削除、管理者権限の制限、定期の見直し、作業の記録を求めます。サービスを使う組織が自分で ID と権限を管理できる機能の提供も求めます。
- [ISO/IEC 27017 がクラウドを使う側と提供する側に求めるアカウント管理](https://www.junify.jp/guides/compliance/iso27017-cloud-account-management.md): ISO/IEC 27017 は推奨の手引です。パスワードの管理では、クラウドを使う会社には事業者の手順が自社の決まりに合うかの確認を、事業者には手順の情報を出すことを勧めています。ID の登録と権限の付与は事業者にだけ手引があります。
- [J-SOX の IT 全般統制の運用評価で、アカウントについて確かめられること](https://www.junify.jp/guides/compliance/jsox-operating-evaluation-accounts.md): 運用評価では、期中に行った利用者の追加・削除・権限の見直しから一部を抜き出し、承認や削除の記録が実際にあるかを確かめます。共有の ID は、本人が使ったことを記録で示せないため、確かめにくくなります。
- [NIST サイバーセキュリティフレームワーク 2.0 の PR.AA を共有アカウントに当てはめる](https://www.junify.jp/guides/compliance/nist-csf-2-identity-management.md): PR.AA は、建物やシステム、データに入れる人を認められた人に限ることを求め、6 項目に分けています。手段は定めませんが、NIST の例は 1 人 1 つの認証情報を挙げており、共有を残すなら使った人の確かめ方と止め方の説明が要ります。
- [金融庁「金融分野におけるサイバーセキュリティに関するガイドライン」が求めるアクセス管理と ID 管理](https://www.junify.jp/guides/compliance/fsa-cybersecurity-guideline-access.md): 中心は 2.3.1「認証・アクセス管理」です。権限を最小限にして承認した個人に付け、アカウントを作成から終了まで管理して棚卸しし、パスワードを管理し、重要なシステムには外から多要素認証で入り、操作を使った人と結びつけて記録するよう求めます。
- [IPA「組織における内部不正防止ガイドライン」第 5 版のアカウント管理項目](https://www.junify.jp/guides/compliance/ipa-insider-threat-guideline-accounts.md): 第 5 版の 33 項目のうち、アカウントを扱うのは主に 6 つです。共有 ID を使わない、退職した人の ID をただちに消すなど 5 つを「しなければならない」とし、利用の記録を残す 1 つは「望ましい」としています。
- [ISMS の担当者が代わるときのアカウントと権限の引き継ぎ](https://www.junify.jp/guides/compliance/isms-handover-accounts.md): 経営者が後任を任命し直し、管理者権限を後任に付けてから、共有パスワードを変え、前任者の権限を外します。審査では、任命と後任の力量の記録、交代前後の権限の一覧、外した記録を示します。
- [PCI DSS の要件 8 は共有 ID をどう扱うか(EC 事業者と運用代行の場合)](https://www.junify.jp/guides/compliance/pci-dss-requirement-8-shared-ids.md): PCI DSS の要件 8 は共有 ID を例外の場面に限り、PCI SSC はそのねらいを、操作を一人ひとりに結びつけることだと説明します。カード情報を持たない EC 事業者も管理画面の二段階認証などを求められ、運用代行もそれに従います。
- [個人情報の管理台帳に、アカウントとアクセス権をどこまで書くか](https://www.junify.jp/guides/compliance/personal-data-ledger-accounts.md): 台帳は法律の義務ではなく、プライバシーマークは「アクセス権を有する者」を求めますが、細かさは決めていません。台帳には部署と役割を書き、氏名とアカウントは別の一覧に分けると直し漏れが減ります。
- [SOC 2 の論理アクセスの規準(CC6.1〜6.3)を SaaS のアカウント管理に当てはめる](https://www.junify.jp/guides/compliance/soc2-logical-access-for-saas.md): CC6.1 は情報資産へのアクセスを仕組みで制限すること、CC6.2 は承認してから ID を発行し不要になれば消すこと、CC6.3 は役割に応じた最小限の権限を求めます。SaaS では一覧・申請と削除の記録・定期の見直しに当たります。
- [個人情報保護法の安全管理措置をアカウント管理に当てはめる](https://www.junify.jp/guides/compliance/appi-safety-measures-for-accounts.md): 通則編の別添が求める「アクセス制御」と「アクセス者の識別と認証」、24 条の従業者の監督、25 条の委託先の監督を、共有アカウント・退職者・委託先の 3 場面に当てはめ、用意する一覧と記録を表にします。
- [IPA「中小企業の情報セキュリティ対策ガイドライン」第 4.0 版のアカウント管理項目](https://www.junify.jp/guides/compliance/ipa-sme-guideline-accounts.md): 第 4.0 版は、ID の発行から削除までの手続、共有 ID を使った人の特定、パスワードの保管ルール、異動・退職時の権限の変更・削除、契約終了時のアクセス権の回収を挙げます。本編・付録 3・付録 5 の当てはまる箇所を点検表にします。
- [ISO/IEC 27001:2022 のアクセス制御の管理策を SaaS に当てはめる](https://www.junify.jp/guides/compliance/iso27001-access-control-for-saas.md): 取り上げる管理策は、5.15 アクセス制御、5.16 識別情報の管理、5.17 認証情報、5.18 アクセス権、8.2 特権的アクセス権の 5 つです。SaaS では、使える人の一覧、ID の作成と削除、パスワード、管理者権限に当たります。
- [経産省サイバーセキュリティ経営ガイドライン(Ver 3.0)の委託先管理](https://www.junify.jp/guides/compliance/meti-cybersecurity-management-guideline-contractors.md): 指示 9 は、委託先を含めた対策状況の把握と、契約での役割と責任範囲の明確化を経営者に求めます。アカウントの操作手順は書かれていないため、委託先に渡すアカウントの一覧と契約の条項に置き換えて読みます。
- [総務省テレワークセキュリティガイドライン第 5 版と私物端末](https://www.junify.jp/guides/compliance/mic-telework-guideline-byod.md): 第 5 版は対策を経営者・管理者・勤務者に分けます。管理者には多要素認証、不要なアカウントの削除、ログイン後の記録の取得を、勤務者には認証情報を無断で貸さないことを求め、私物端末はテレワークの方式ごとに可否を決めます。
- [プライバシーマーク(JIS Q 15001)でアカウント管理について求められること](https://www.junify.jp/guides/compliance/privacy-mark-account-management.md): JIPDEC の構築・運用指針は、個人情報の台帳に「アクセス権を有する者」を書いて年 1 回以上確認すること、従業者の監督、委託先の選定基準と契約の 8 事項を求めます。アカウントでは、使える人の一覧・記録・契約の条項に当たります。
- [不正アクセス禁止法と ID・パスワードの共有(識別符号の扱い)](https://www.junify.jp/guides/compliance/unauthorized-computer-access-law-shared-ids.md): 会社が契約するサービスの共有 ID を、会社の承諾を得た担当者が使う行為は、不正アクセス行為から除かれると読めます。退職者の利用、委託先への提供、社外に教える行為は、承諾の範囲と 5 条の「業務その他正当な理由」で分かれます。
- [ISMS(情報セキュリティマネジメントシステム)とは](https://www.junify.jp/guides/compliance/what-is-isms.md): ISMS とは、情報を守るための方針・体制・手順を組織として決め、運用し、見直す仕組みです。国際規格 ISO/IEC 27001 に沿って作り、第三者の審査を受けて認証を取ることができます。
- [IT 全般統制(ITGC)とは](https://www.junify.jp/guides/compliance/what-is-itgc.md): IT 全般統制とは、金融庁の実施基準で「業務処理統制が有効に機能する環境を保証するための統制活動」とされるもので、システムの開発・保守、運用・管理、アクセス管理などの安全性の確保、外部委託契約の管理が例に挙がります。
- [安全管理措置とは](https://www.junify.jp/guides/compliance/what-is-security-control-measures.md): 安全管理措置とは、個人情報保護法 23 条が事業者に義務づける、個人データの漏えい・滅失・毀損を防ぐ対策です。通則編の別添が、組織的・人的・物理的・技術的の 4 区分と外的環境の把握で内容を示します。
- [SOC 2 とは](https://www.junify.jp/guides/compliance/what-is-soc2.md): SOC 2 とは、クラウドなどのサービスを提供する会社の内部統制を、公認会計士が AICPA の Trust サービス規準に照らして検証し報告する仕組みです。セキュリティなど 5 つの区分で見ます。
- [公表された事故から、アカウント管理の何が問われたか](https://www.junify.jp/guides/incidents.md): 辞めた人のアカウントが生きていた、委託先の担当者がパスワードを知っていた。公表された事故の原因は、この 2 つに行き着きます。どちらも業種や規模を選びません。
- [退職を申し出てから退職日までに技術情報を持ち出された事案から分かる、退職予定者の権限の扱い](https://www.junify.jp/guides/incidents/access-between-resignation-notice-and-last-day.md): 秘密保持契約を結んでいた元社員が、退職を申し出てから退職するまでの間に営業秘密に当たる技術情報を持ち出したとして逮捕されました。会社は再発防止策に、退職予定者のアクセス権限の停止・制限の強化を挙げています。
- [代行会社の Google アカウントへの不正アクセスで公式 X と YouTube が乗っ取られた事案](https://www.junify.jp/guides/incidents/agency-google-account-breached.md): 代行会社が使用・管理する Google アカウントへの不正アクセスをきっかけに、公式 X で無関係な投稿が、YouTube でチャンネル名の変更や動画の削除が行われました。
- [委託先のパソコンの感染が社内システムへの侵入につながった事案から分かる、ログインの仕組みの共有](https://www.junify.jp/guides/incidents/contractor-pc-malware-shared-auth.md): 委託先の従業者のパソコンが悪意のあるプログラムに感染し、関係会社と共通のログインの仕組みでつながっていた社内システムに侵入されました。ユーザー・取引先・従業者の情報 44 万件が漏えいしました。委託先と何を共有しているかが問われました。
- [委託先の担当者が顧客情報を外部へ持ち出した事案から分かる、委託元が持つ記録と監視](https://www.junify.jp/guides/incidents/contractor-sent-data-outside.md): 委託先の元派遣社員が業務用パソコンから個人契約の外部ストレージへ顧客情報約 596 万件を持ち出しました。委託元のネットワーク監視が当日に検知しています。委託先で起きたことを委託元が自分の記録で見つけられるか、が問われた事案です。
- [委託先の保守担当者が管理者アカウントを共用していた事案から分かる、管理者権限と記録](https://www.junify.jp/guides/incidents/contractor-shared-admin-account.md): コールセンターの仕組みを保守する委託先の元派遣社員が、約 10 年間、管理者用のアカウントで顧客情報を持ち出しました。共用の管理者アカウント、持ち出しを止める設定の不在、記録を点検する運用の不在が原因として公表されています。
- [退職の直前に顧客情報を持ち出された事案から分かる、退職時の業務情報の扱い](https://www.junify.jp/guides/incidents/documents-taken-just-before-resignation.md): 旅行事業の営業担当だった元従業員が、退職直前に宿泊施設の担当者と社内の従業員の個人情報を含む社内資料を持ち出しました。判明は退職の 1 年余り後で、会社は退職・異動時の業務情報の取り扱いを見直すとしています。
- [退職者にサーバーのデータを消された事案から分かる、遮断と復旧の備え](https://www.junify.jp/guides/incidents/former-employee-deleted-data.md): 退職した元社員が退職後に社内ネットワークに不正にアクセスし、サーバーのデータを削除して業務を妨害した容疑で逮捕されました。持ち出しではなく消される型で、遮断と復旧の両方が問われます。
- [退職後に元職員がシステムにログインした事案から分かる、退職日に利用を止める手順](https://www.junify.jp/guides/incidents/former-staff-login-after-leaving.md): 小学校を退職した臨時的任用講師が、退職後に市の学校教育支援システムへ不正にアクセスしたとして逮捕されました。市の公表文は入った経路を書いておらず、問われるのは退職日に利用を止める手順です。
- [退職日の翌日にアカウントが残っていた事案から分かる、退職手続きとアカウント削除のつなぎ方](https://www.junify.jp/guides/incidents/former-staff-took-files-before-and-after-leaving.md): 元職員が在職中と退職日の翌日に、個人情報を含むファイルを USB メモリで持ち出しました。市は原因の一つに、退職翌日もアカウントの削除処理が行われていなかったことを挙げています。
- [再々委託先の作業者が仕入先の個人情報をダウンロードした事案から分かる、多層の委託とアクセス権限](https://www.junify.jp/guides/incidents/fourth-tier-contractor-downloaded-data.md): 委託先・再委託先の先にいる再々委託先の作業者が、仕入先担当者の個人情報約 2.2 万件を私用目的でダウンロードしました。委託の階層が深くなるほど、委託元から作業者が見えにくくなります。誰にどの範囲の権限を与えているかが問われた事案です。
- [公式 SNS が乗っ取られた 9 件の公表文から分かること](https://www.junify.jp/guides/incidents/official-sns-takeovers-from-notices.md): 公表文 9 件のうち、原因を書いたのは 1 件です。多くは「調査中」「再発防止に努める」にとどまります。乗っ取り後に起きたことと、公表文が挙げた対策を表にします。
- [公式 Instagram が運営元を装ったメールで乗っ取られ、削除された事案](https://www.junify.jp/guides/incidents/phishing-took-over-official-sns.md): 公式 Instagram が、運営元を装ったメールへの対応をきっかけに乗っ取られ、管理情報を無効化されたうえ削除されました。公表文で乗っ取りの原因を書いた例です。
- [管理者パスワードの使い回しでランサムウェアの被害が院内に広がった事案](https://www.junify.jp/guides/incidents/reused-admin-password-ransomware.md): 保守用の外部接続機器と院内すべてのパソコンで、同じ推測しやすい ID とパスワードが使われ、全利用者に管理者権限がありました。調査報告書は、原因の多くは国のガイドラインを守っていれば防げたとしています。
- [パスワードの使い回しで法人向けサービスの管理画面に不正ログインされた事案](https://www.junify.jp/guides/incidents/reused-password-list-attack.md): 他のサービスから漏れた ID とパスワードの組を試す攻撃で、二段階認証をオフにしていた ID だけが不正ログインされました。国内 12 件、海外を含め 156 件です。
- [退職後に社外の Web サービスへ不正アクセスされた事案から分かる、外部サービスのアカウントの止め方](https://www.junify.jp/guides/incidents/saas-account-alive-after-resignation.md): 元従業員が退職後に、会社が利用する名刺管理システムに不正にアクセスし、名刺情報を漏えいさせました。問われるのは、会社が使うシステムのアカウントを退職時に止める手順です。社外の Web サービスなら、社内の手続きだけでは止まりません。
- [委託先と共通のパスワードから侵入されてランサムウェアの被害が広がった事案](https://www.junify.jp/guides/incidents/shared-password-with-supplier.md): 給食の委託先の機器から侵入され、病院のサーバーと端末で共通だったパスワードで被害が広がりました。報告書が原因に挙げたのは、共通パスワード、全員への管理者権限、外部接続の役割分担の曖昧さです。
- [共有ツールの ID とパスワードが盗まれて侵入された事案から分かる、ID の発行と管理、多要素認証](https://www.junify.jp/guides/incidents/shared-tool-ids-used-for-intrusion.md): 正規の ID とパスワードが盗まれ、正常なログインに見える形で顧客から預かった情報が窃取されました。影響は 142 の顧客に及び、検証委員会は情報保護の体制と利用組織ごとの管理の不備を指摘しました。
- [無断の再委託先が個人データを持ち出した事案から分かる、再委託と辞めた人が知っているパスワード](https://www.junify.jp/guides/incidents/undisclosed-subcontractor-copied-data.md): 全市民約 46 万人の個人データを入れた USB メモリーを、市に無断の再々委託先の従業員が持ち出して紛失しました。調査報告書は、無断の再委託と、案件を離れた人や転職した人もパスワードを知ったままだった状態を、問題として明記しています。
- [個人情報保護委員会の指導事例に出てくる、推測されやすいパスワードと委託先のアカウント](https://www.junify.jp/guides/incidents/weak-and-default-passwords-in-guidance.md): 令和 6 年度第 1 四半期の指導 110 件の概要には、事業名を使った簡単なパスワード、4 桁の管理者パスワード、初期設定のままの ID が原因とされた事案が並びます。委託先の監督の不備も 8 件ありました。
- [漏えい等とは(個人情報保護法の報告義務)](https://www.junify.jp/guides/incidents/what-is-data-breach.md): 漏えい等とは、個人データの漏えい・滅失・毀損をまとめた言葉です。個人情報保護法 26 条は、規則で定める 4 つの事態が起きたとき、個人情報保護委員会への報告と本人への通知を義務づけます。
- [内部不正とは](https://www.junify.jp/guides/incidents/what-is-insider-threat.md): 内部不正とは、役員・従業員・派遣社員などの内部者による、情報の窃取・持ち出し・漏えい・消去・破壊です。IPA のガイドラインは、違法とまでいえない規程違反も含め、退職後に在職中の情報を漏らす行為も内部不正として扱います。
- [不正アクセスとは(不正アクセス禁止法)](https://www.junify.jp/guides/incidents/what-is-unauthorized-access.md): 不正アクセスとは、不正アクセス禁止法 2 条 4 項が定める行為で、中心は、他人の ID とパスワード(識別符号)をネットワーク経由で入力し、制限されている利用ができる状態にすることです。3 条が禁じ、11 条に罰則があります。
- [アカウント管理の用語索引](https://www.junify.jp/glossary.md): アカウント管理に関する用語を、読みの五十音順で探せます。
- [よくある質問](https://www.junify.jp/faq.md): Junify の仕組みや利用条件について、現場ごとのよくある質問にお答えします。

## 問い合わせ

- デモの予約: https://www.junify.jp/bpo/demo
- メール: info@junify.com