第644回 SORACOM公式ブログ

ソラコム公式ブログ

【SORACOM Napter】SIM グループ単位でリモートアクセスの作業者を分ける方法

2026年09月18日 16時00分更新

　本記事はソラコムが提供する「SORACOM公式ブログ」に掲載された「【SORACOM Napter】SIM グループ単位でリモートアクセスの作業者を分ける方法」を再編集したものです。

こんにちは、ソリューションアーキテクトの守谷 (ニックネーム: moris) です。

今日は、SORACOM Napter でリモートアクセスを実施する 作業者を分けたい 場合の権限設定について、新しく使えるようになった API を使った運用方法をご紹介します。

あらたに所属SIMグループごとに分けてSIMを表示できるようになり、Napterによるリモートアクセスの権限を管理しやすくなりました！

リモートアクセスを実施する作業者を分けたい

SORACOM Napter は、SIM を指定するだけでそのデバイスに SSH や HTTP でアクセスできる機能で、遠隔地のデバイスのメンテナンスや障害調査用途で多くのお客様にご利用いただいています。ご利用が広がるにつれて、次のようなご相談をいただくことが増えてきました。

自社のデバイスを遠隔でメンテナンスするサービスを提供しているが、実際の作業は複数の担当者や協力会社で分担している
担当者ごとに担当する設備が決まっており、担当外の設備にはアクセスさせたくない
アクセスさせないだけでなく、担当外の設備の情報 (SIM の名前、設置場所を表すタグ、オンライン状態など) も見せたくない
担当する設備が増減するたびに権限設定を修正する運用は避けたい

SORACOM には SAM (SORACOM Access Management) という仕組みがあり、アカウントの所有者 (ルートユーザー) とは別に、使える機能を絞った SAM ユーザーを作業者ごとに発行できます。ところが、SAM ユーザーに SORACOM Napter の権限を与えると、以前は オペレーター（アカウント）内のすべての SIM にリモートアクセスできてしまいました。

2025 年 9 月に SIM 単位でオンデマンドリモートアクセスを作成する API (PortMapping:createPortMappingForSim) が追加され、SAM の条件式に SIM ID を書くことで「この SIM にだけリモートアクセスを許可」という権限を作れるようになりました (設定方法はこちらの記事で解説しています)。接続先を絞るという目的はこれで達成できるのですが、冒頭のご相談に当てはめてみると、まだ 2 つの問題が残ります。

1 つ目は、設備が増減するたびに権限を書き換える必要があることです。 権限には SIM ID を 1 枚ずつ列挙するため、担当する設備が 1 台増えるたびに、SAM ロールの JSON を開いて SIM ID を追記する作業が発生します。設備が数十台になると JSON も長くなり、間違いも起きやすくなります。また、権限の記述の文字数にも制限があり、あまり多数のSIM IDを列挙することはできません。

2 つ目は、作業者に担当外の SIM の情報が見えてしまうことです。 作業者がリモートアクセスする SIM を選ぶには、SIM の一覧が必要です。ところが SIM の一覧を取得する権限 (API や CLI なら Sim:listSims、ユーザーコンソールの SIM 一覧画面なら Query:searchSims) は、どちらもオペレーター内の全 SIM が対象で、「一部の SIM だけ」に絞ることができません。これらの権限を与えると、リモートアクセスできない SIM も含めて全 SIM の情報が見えてしまいます。SAM のドキュメントにも「SIM グループごとに閲覧の可否を制御することはできません」と書かれているとおり、これまで「一部の SIM だけを見せる」手段はありませんでした。

Sim:listSims や Query:searchSims の権限を与えず、全くSIMを見せないようにする運用も可能ですがそれでも1つ目の問題は残ります。また、作業者ごとにオペレーター (アカウント) を分ければ情報は完全に分離できますが、契約や請求、管理画面まで分かれてしまい、1 つのサービスとして運用するには大がかりです。「担当する設備をグループにまとめておいて、作業者にはそのグループの SIM だけを見せ、そのグループの SIM だけにリモートアクセスさせたい」というのが、今回の記事で実現したいことです。

今回の変更で何が変わるか

2026 年 9 月に、グループに所属する IoT SIM の一覧を取得する API が利用できるようになりました。ユーザーコンソールの SIM 一覧画面が使う検索 API のグループ版 Query:searchSimsByGroup (GET /query/sims_by_group/{group_id}) と、SIM 一覧 API のグループ版 Group:listSimsInGroup (GET /groups/{group_id}/sims) の 2 つです。どちらも指定したグループに所属する SIM の一覧を、これまでの SIM 一覧・検索 API と同じ形式で返します。

これらの API のポイントは、グループ ID が API のパスに含まれている ことです。SAM のパーミッション構文では pathVariable 関数を使って、API のパスに含まれる値を許可の条件にできます。つまり、次のような権限を SAM ユーザーに与えると、その作業者は指定したグループの SIM だけを一覧できるようになります。

{   "effect": "allow",   "api": ["Query:searchSimsByGroup", "Group:listSimsInGroup"],   "condition": "pathVariable('group_id') == 'グループ ID'" }

他のグループの SIM は一覧できません。オペレーター全体の SIM 一覧 (Sim:listSims) や SIM 検索 (Query:searchSims) の権限を与えなければ、作業者から見える SIM はこのグループの分だけになります。

ユーザーコンソール側にもこれに対応した変更があります。SIM グループの画面に 「このグループに所属している SIM」だけを表示する専用ページ (https://console.soracom.io/groups/<グループ ID>/sims) が追加されました。このページは Query:searchSimsByGroup だけで表示でき、グループ一覧やグループ設定を読む権限を必要としません。作業者にこのページの URL を渡しておけば、作業者はユーザーコンソールにログインして、自分のグループの SIM だけが並ぶ画面からオンデマンドリモートアクセスを作成できます。

SIMグループごとにSIMを表示する画面。ここからリモートアクセスなどの操作も可能

「このグループに所属しているSIM」の画面には、グループの詳細画面から遷移することができます（赤枠のボタン）

先ほどの 2 つの問題は、これでどちらも解消できます。

設備の増減: 権限に書くのはグループ ID だけなので、設備が増えたら SIM をグループに入れ、減ったらグループから外すだけです。権限設定は書き換えません。グループの操作はユーザーコンソールの通常機能なので、SAM の JSON を触れる人でなくても運用できます
担当外の SIM の情報: 作業者に見えるのは、グループに入っている SIM だけです。SIM 管理画面や SIM グループ一覧を開いても権限エラーになり、他の SIM の情報は表示されません

なお、オンデマンドリモートアクセスを作成する API そのものはグループで絞ることができないため、「SIM ID を知っていればグループ外の SIM にも接続できてしまう」という弱点が残ります。この点は記事の後半「知っておくべきリスクと対策」で詳しく説明します。

実際にSAMユーザーを作って試す

SIMグループ単位で Napterの作業者を分ける構成を以下のように作ってみます。

登場人物は 2 者です。

管理者 (SIM の所有者) は、作業者に任せる SIM を入れる SIM グループを作り、そのグループに限定した SAM ロールを作成し、作業者ごとに SAM ユーザーを発行して、ログイン情報とグループの SIM 画面の URL を渡します
作業者 (担当者・協力会社) は、渡された URL からユーザーコンソールにログインし、自分のグループの SIM の中から対象を選んでオンデマンドリモートアクセスを作成し、デバイスに SSH や HTTP で接続します

SIM ID を列挙する方式との違いを表にまとめます。

項目	SIM ID を列挙する方式	SIM グループで指定する方式
権限に書くもの	SIM ID を or で列挙	グループ ID を 1 つ
SIM を追加するとき	SAM ロールの JSON を編集	SIM をグループに入れるだけ
作業者から見える SIM	SIM 管理画面を使うと全 SIM が見える	グループの SIM だけ
作業者の操作画面	ユーザーコンソールの SIM 管理画面	ユーザーコンソールのグループの SIM 画面
権限外の SIM へのリモートアクセス	権限で拒否される	SIM ID を知っていればアクセスできる (後述の「リスクと対策」参照)

最後の行が今回の方式の弱点です。詳しくは記事の後半で説明しますので、ここでは「一覧はグループで絞れるが、リモートアクセスの作成そのものはグループで絞れない」と覚えておいてください。

作業者に与える権限 (SAM ロール)

前置きが長くなりましたが、いよいよ具体的な設定に入っていきます。まずは作業者の SAM ユーザーに与えるパーミッション構文です。
SAMユーザーの作成方法についてはこちらのドキュメントを参照ください。

{   "statements": [     {       "effect": "allow",       "api": ["Query:searchSimsByGroup", "Group:listSimsInGroup", "Group:getGroup"],       "condition": "pathVariable('group_id') == '12345678-1234-1234-1234-123456789abc'"     },     {       "effect": "allow",       "api": [         "PortMapping:createPortMappingForSim",         "PortMapping:listPortMappingsForSim",         "PortMapping:deletePortMapping",         "Subscriber:getSubscriber"       ]     }   ] }

12345678-1234-1234-1234-123456789abc の部分は、実際のグループ ID に置き換えてください。グループ ID はユーザーコンソールのグループ詳細画面の URL、または soracom groups list コマンドで確認できます。

各ステートメントブロックの意味は次のとおりです。

1 つ目のブロック が今回の主役で、指定したグループに対してだけ、グループ内の SIM の検索 (Query:searchSimsByGroup) と一覧 (Group:listSimsInGroup)、グループ情報の取得 (Group:getGroup) を許可しています。ユーザーコンソールのグループの SIM 画面が使うのは Query:searchSimsByGroup です。Group:listSimsInGroup は SORACOM CLI や API から一覧を取る場合に、Group:getGroup はグループ名を確認したい場合に使うもので、ユーザーコンソールだけで運用するなら無くても構いません。複数のグループを任せる場合は、条件式を or pathVariable(‘group_id’) == ‘…’ でつなぎます。

2 つ目のブロック は SORACOM Napter の操作です。オンデマンドリモートアクセスの作成 (createPortMappingForSim)、SIM ごとの一覧 (listPortMappingsForSim)、削除 (deletePortMapping) に加えて、ユーザーコンソールのオンデマンドリモートアクセス画面が SIM のオンライン状態を確認するために使う Subscriber:getSubscriber を許可しています。このブロックには条件を付けていません。これらの API のパスにはグループ ID が含まれないため、グループで絞り込む条件が書けないからです。

なお、SIM 管理画面 (全てのSIMを一覧できる画面）から SIM を選んでリモートアクセスを作成する運用にしたい場合は、SIM 管理画面用の権限 (Query:searchSims と Group:listGroups) が別途必要になり、その時点で他の SIM も見えてしまいます。今回の方式は「作業者は SIM 管理画面ではなく、グループごとの SIM 画面を使う」ことが前提です。

設定手順 (管理者)

作業者に任せる SIM をグループに入れる

まず、作業者に任せる SIM を入れるグループを作ります。すでに運用中のグループをそのまま使っても構いませんが、グループには SORACOM Air や SORACOM Beam などのサービス設定も紐付くため、「担当範囲を表すグループ」を新しく作るほうが分かりやすいと思います。ここでは「保守担当-A社」という名前にしました。

グループの作成と SIM の所属変更の手順はグループを作成すると IoT SIM が所属するグループを切り替えるをご確認ください。

ユーザーコンソールのグループ画面。グループ「保守担当-A社」に担当する SIM が所属している

権限設定のため、グループの ID (赤枠部分) をメモしておきましょう。

SAM ロールを作成する

ユーザーコンソール右上のユーザー名をクリックし、「セキュリティ」→「ロール」→「オペレーター管理ロールを作成」の順に進みます。ロール名は「Napter_保守担当-A社」のようにグループ名が分かる名前にし、権限設定の欄に先ほどのパーミッション構文を貼り付けます。グループ ID の部分をメモした値に置き換えるのを忘れないでください。ロールの作成手順はオペレーター管理ロールを作成するをご確認ください。

作業者の SAM ユーザーを作成し、ロールをアタッチする

続いて、作業者用の SAM ユーザーを作成し、「認証設定」からパスワードを設定します。さらに、ユーザーの設定画面の「ロール指定」から先ほどのロールをアタッチします。それぞれ以下のドキュメントを参考にしてください。

作業者には、次の 3 つを渡します。

ログイン情報: オペレーター ID、SAM ユーザー名、パスワード
グループの SIM 画面の URL: https://console.soracom.io/groups/<グループ ID>/sims
オンデマンドリモートアクセスの使い方: ユーザーコンソールでオンデマンドリモートアクセスを作成する

作業者はグループ一覧を開く権限を持たないため、URL を直接開く必要があります。ブラウザのブックマークに登録してもらうとよいでしょう。

SAM ユーザーは作業者ごとに 1 つ発行することをおすすめします。 SORACOM Napter の監査ログと API 監査ログはどちらも SAM ユーザー単位で記録されるため、「誰がいつどのデバイスに接続したか」をあとから追えるようになります。担当者が交代したら SAM ユーザーを削除するだけで、権限の引き継ぎ漏れも起きません。

SORACOM Napter でリモートアクセスを誰が、いつ、どのSIMに対して使ったか、を後から知るために Napter 監査ログという機能があります。こちらは無料でも24時間分は見ることができますが、有料オプションを有効化することで 366日分のログを見ることができるようになります。
この記事のような体制でNapterを利用される場合は必須の機能と言えるのではないでしょうか。

Napter 監査ログ利用オプション料金はこちらをご確認ください。

作業者として確認する

それでは、作成した SAM ユーザーでユーザーコンソールにログインして、作業者にはどう見えるのかを確認していきましょう。ログイン画面の SAM ユーザー用フォームに、オペレーター ID、ユーザー名、パスワードを入力します (ルートアカウント用の画面が表示された場合は「SAM ユーザーでログイン」に切り替えてください)。

SIM 管理画面には何も表示されない

ログイン後、メニューから「SIM 管理」を開いてみます。SIM 管理画面に必要な Query:searchSims と Group:listGroups の権限が無いため、権限エラーが表示され、SIM は 1 枚も表示されません。

「SIM グループ」の一覧も同じです。Group:listGroups の権限が無いため、グループの一覧は表示されません。作業者はどんなグループがあるのかも分からない状態です。

グループの SIM 画面には担当する SIM だけが表示される

次に、管理者から渡された URL (https://console.soracom.io/groups/<グループ ID>/sims) を開きます。「このグループに所属している SIM」というページが表示され、グループに入れた SIM だけが一覧に並びます。オンライン状態や状態 (使用中など) も確認できます。

オンデマンドリモートアクセスを作成する

一覧から対象の SIM にチェックを入れ、「操作」メニューから「オンデマンドリモートアクセス」を選びます。

SIM 管理画面から開いたときと同じオンデマンドリモートアクセスの画面が表示されます。接続方法、デバイス側のポート、アクセス可能時間を指定して「保存」をクリックします。

接続先のホスト名とポート番号、SSH や HTTP でのアクセス例が表示されました。あとは通常どおり、表示されたコマンドや URL でデバイスに接続するだけです。詳しい手順は SORACOM Napter のドキュメントをご確認ください。

他のグループの SIM 画面は表示されない

最後に、URL のグループ ID を別のグループのものに書き換えて開いてみましょう。パーミッション構文の condition で許可したグループ以外は Query:searchSimsByGroup が拒否されるため、権限エラーになり SIM は表示されません。

作業者が「自分のグループの SIM だけを見て、そこからリモートアクセスできる」状態になっていることが確認できました。

SIM を追加してみる

管理者側で、新しい SIM をグループ「保守担当-A社」に入れてみましょう。作業者がグループの SIM 画面を再読み込みすると、追加した SIM がすぐに一覧に現れます。SAM ロールの権限設定には手を触れていません。担当から外すときも、グループから SIM を外すだけです。

グループに SIM を追加した後の作業者側の画面。追加した SIM が一覧に現れている

知っておくべきリスクと対策

この方式を採用する前に、必ず以下のリスクを理解しておいてください。

リスク 1: SIM ID を知っていれば、グループ外の SIM にもリモートアクセスを作成できる

これが最も重要な点です。オンデマンドリモートアクセスを作成する API PortMapping:createPortMappingForSim のパスには SIM ID しか含まれないため、グループで絞り込む条件を書くことができません。 今回の権限では無条件で許可しているので、作業者が何らかの方法でグループ外の SIM の SIM ID を知った場合、その SIM に対してもリモートアクセスを作成できてしまいます。ユーザーコンソールの画面からは SIM を選べませんが、API を直接呼べば作成が成功します。

一方で、その SIM の情報を取得する Sim:getSim は許可していないので拒否されます。「画面には出ないが、ID を知っていれば接続はできる」という状態です。

SIM ID は秘密情報として扱われるものではなく、SIM の台紙や出荷時の書類、ユーザーコンソールのさまざまな画面に表示されます。「作業者は SIM ID を知らないはず」という前提に頼るのは危険です。対策を組み合わせて、リスクを許容できる範囲に抑えましょう。

接続元 IP アドレスを制限する。 パーミッション構文の ipAddress 関数を使い、”condition”: “ipAddress(‘198.51.100.0/24’)” のように作業者の拠点からしかユーザーコンソールや API を使えないようにします。オンデマンドリモートアクセス自体にも接続元 IP アドレスの制限があり、作成時に指定できます
期間を限定する。 currentDate と date() を組み合わせて、契約期間や作業期間だけ有効な権限にします
不要なSAMユーザーの権限を無効化する。担当を外れた作業者のSAMユーザーを削除する、ロールを外すなどによって権限を無効化する。
特に守りたい SIM は deny で明示的に拒否する。 こちらの記事で紹介した “effect”: “deny” と pathVariable(‘sim_id’) の組み合わせで、基幹設備など絶対に触らせたくない SIM を拒否リストに入れておきます。同じ API に許可と拒否の両方が該当する場合は拒否が優先されます
デバイス側の認証を省略しない。 SORACOM Napter が提供するのはデバイスまでの「到達性」です。SSH の鍵認証や Web アプリのログインなど、デバイス側の認証は必ず有効にしておいてください
Napter 監査ログを見る。 SORACOM Napter の監査ログには、どの SAM ユーザーがどの SIM に対してリモートアクセスを作成したかが記録されます。グループ外の SIM への作成が記録されていないか、定期的に確認する運用にしておくと安心です。またその際は、Napter 監査ログ利用オプションを有効化し、ログの保持期間を366日に延長することも必要です。
厳密にグループ外を拒否したい場合は、SIM ID を列挙する方式にする。 SIM ID を pathVariable(‘sim_id’) で列挙すれば、作成 API も SIM 単位で拒否できます。追従性を取るか厳密さを取るかは、作業者との信頼関係や設備の重要度で判断してください

リスク 2: IMSI を知っていれば、グループ外の SIM の情報を取得できる

ユーザーコンソールのオンデマンドリモートアクセス画面が必要とする Subscriber:getSubscriber (GET /subscribers/{imsi}) も、パスに含まれるのが IMSI であるためグループで絞れず、無条件で許可しています。作業者が他の SIM の IMSI を知っていれば、API でその SIM の情報 (名前、タグ、セッション情報など) を取得できます。リスク 1 と同じく、接続元 IP アドレスや期間の制限を組み合わせてください。作業者が API を使わずユーザーコンソールだけで作業する運用であれば、画面からこの情報に到達することはありません。

リスク 3: 一覧に含まれる SIM の情報がそのまま見える

グループの SIM 画面には、SIM 管理画面と同じく IMSI や状態、タグなどが表示されます。SIM の名前やタグにお客様名や設置場所を書いている場合、それらも作業者に見えることになります。作業者に見せてよい情報だけをタグに書くようにしてください。

リスク 4: 共有アカウントにしない

先ほども触れましたが、複数の作業者で 1 つの SAM ユーザーを共有すると、監査ログで個人を特定できなくなります。作業者ごとに SAM ユーザーを発行し、退任時には削除してください。多要素認証 (MFA) の有効化も検討してください。

まとめ

いかがでしたでしょうか。

新しく利用できるようになったグループ単位の SIM 一覧 API を pathVariable(‘group_id’) で絞り、ユーザーコンソールの「このグループに所属している SIM」画面と組み合わせることで、作業者には担当するグループの SIM だけを見せ、SIM の追加や削除はグループへの出し入れだけで済む運用を組み立てました。作業者は普段どおりユーザーコンソールからオンデマンドリモートアクセスを作成できます。

一方で、リモートアクセスの作成 API はグループで絞れないため、SIM ID を知っていればグループ外の SIM にも接続できてしまう点には注意が必要です。接続元 IP アドレスの制限、期間の限定、deny による明示的な拒否、監査ログの確認を組み合わせて、設備の重要度に見合った守り方を選んでください。

ご参考になればと思います。それでは！

― ソラコム守谷（moris）

投稿【SORACOM Napter】SIM グループ単位でリモートアクセスの作業者を分ける方法は SORACOM公式ブログに最初に表示されました。

ツイートする

soracom トップへ