目次
Notionを外部のツールとつなぐとき、「このページを連携先に見せる」という感覚で設定していると思います。実際、設定画面もそういう作りです。
ところが実際に接続したインテグレーションから何が取れるのかを調べたら、共有したページの外にあるものまで見えていました。
この記事では、実際にAPIを叩いて取れたものと、取れなかったものを並べます。外部サービスにトークンを渡すかどうかを判断する材料として使ってください。
共有したページの外にも、見えているものがある
先に結果です。ページの共有範囲とは関係なく取れたものを並べます。
| 取れたもの | 中身 |
|---|---|
| メンバーの一覧 | 名前とメールアドレス |
| 他のインテグレーション | 名前（どのツールと連携しているか） |
| ワークスペースの情報 | 名前と識別子 |
| ページの作成者・最終編集者 | 誰が作って、誰が最後に触ったか |
メールアドレスまで返ってくる
いちばん意外だったのがこれです。ユーザー一覧を取得すると、ワークスペースに参加している人の名前だけでなく、メールアドレスが一緒に返ってきました。
共有しているページは1つだけの状態で試しています。それでも、そのページと関係のないメンバーまで含めて、全員ぶんが返りました。
社内のメールアドレスは、それ自体が情報です。命名規則が分かれば、名簿にない人のアドレスも推測できます。外部サービスにトークンを渡すということは、これも一緒に渡すということです。
他にどんなツールを入れているかも分かる
同じ一覧には、そのワークスペースに追加されている他のインテグレーションの名前も並びました。
人とツールは種別で区別されていますが、どちらも同じ一覧に出てきます。名前はそのまま見えるので、どんなツールと連携しているかが把握できます。
誰が作って、誰が触ったかも残っている
ページの情報には、作成者と最終編集者が記録されていました。返ってくるのは識別子だけですが、その識別子をユーザー一覧で引けば名前に変わります。
つまり、共有したページについては「誰がいつ何を書いたか」まで追えます。議事録や評価メモを共有していると、そこに書いた人の名前も一緒に渡ります。
逆に、見えなかったもの
全部が見えるわけではありませんでした。ここが大事なところです。
コメントは読めなかった
ページに付いているコメントを取得しようとしたところ、拒否されました。返ってきたのは403で、「このエンドポイントには権限が足りません」というメッセージです。
ページ本体は読めるのに、コメントは読めません。同じページの中でも、扱いが分かれているということです。
つまり、権限は分けて渡せる
この結果から分かるのは、インテグレーションの権限が「全部入り」ではないことです。作るときに、何を許すかを選べます。
今回使ったものは、ページの読み書きは許可されていて、コメントの読み取りは許可されていませんでした。だから同じトークンでも、できることとできないことがあります。
人とツールは、返り方で見分けられる
一覧に並ぶとき、人とツールは種別で区別されています。人には所属情報の欄があり、そこにメールアドレスが入ります。ツールのほうにはその欄がなく、代わりに所有者の情報が入ります。
つまりメールアドレスが返るのは人だけで、ツールからは取れません。逆に言えば、人が1人でもいれば、その人のアドレスは見えているということです。
担当者の欄には、ツールも入れられた
ついでに試したのですが、担当者を入れる欄に、人だけでなくツールも割り当てられました。エラーにならず、普通に登録できます。
実務で使う場面は少ないものの、自動化で担当者を埋める処理を書いているときに、意図せずツール自身が担当者になることがあります。担当者で絞り込んだ集計をしていると、その行が数え漏れます。
権限には粒度がある
ここを知っていると、渡す前の判断が変わります。
最小限にしておけば、事故の範囲が狭くなる
インテグレーションを作るときには、読み取りだけ、書き込みも、コメントも、ユーザー情報も、といった単位で許可を選べます。
よくあるのは、面倒なので全部許可してしまうケースです。動かないときの切り分けが減るので気持ちは分かりますが、トークンが漏れたときの被害範囲が広がります。
連携先が読むだけの用途なら、書き込みは許可しない。ユーザー情報が要らないなら、そこも外す。この一手間で、万一のときの範囲が変わります。
ユーザー情報の許可は、特に効く
今回メールアドレスが取れたのは、ユーザー情報の取得が許可されていたからです。ここを外せば、メンバーの一覧そのものが取れなくなります。
連携の目的が「データベースの中身を同期する」だけなら、ユーザー情報は不要なことが多いです。担当者名を同期したい場合だけ必要になります。
迷ったら外して、動かなければ足す。この順番のほうが安全です。
図にすると、こういう関係です
許可の種類と、それぞれで何ができるか
許可の単位を整理しておきます。組み合わせて指定するので、必要なものだけを選べます。
| 許可 | できること | 外せる場面 |
|---|---|---|
| 読み取り | 共有されたページとデータベースを読む | 書き込み専用の用途 |
| 更新 | 既存のページの中身を書き換える | 読むだけの同期 |
| 追加 | 新しいページや行を作る | 既存を更新するだけの用途 |
| コメント | コメントを読む・書く | ほとんどの用途で不要 |
| ユーザー情報 | メンバーの一覧とメールアドレス | 担当者名を扱わない同期 |
この表でいちばん外す価値があるのが、下2つです。コメントとユーザー情報は、必要な場面が限られます。にもかかわらず、付けたままにされていることが多い項目でもあります。
チームで使うときに効いてくる話
1人で使っているぶんには、ここまでの話はそこまで重くありません。人が増えると変わります。
誰でも追加できてしまう
問題は、インテグレーションを追加できる人の範囲です。メンバーが自分のページに連携を足す場合、それが全体から見えているとは限りません。
気づいたら、誰かが入れた外部ツールがワークスペースのメンバー一覧を読んでいた、ということが起こり得ます。しかも、そのツールの名前は他のインテグレーションからも見えます。
上位プランだと管理の手段が増える
ここが有料プランを検討する理由の1つになります。公式の料金ページによると、上位のプランでは、細かい権限の設定、プライベートなチームスペース、ドメインの認証、シングルサインオンといった管理の仕組みが使えます。
人数が増えるほど、「誰が何を入れたか」を把握する手間が増えます。人力で見て回るコストと、プランの差額を比べる段階が来ます。
判断の目安は「把握できているか」
いま入っているインテグレーションを全部言えるなら、まだ管理できています。言えないなら、すでに把握できていません。
この記事の方法で一覧を取れば、実際に何が入っているかが分かります。思っていたより多かったなら、それが判断の材料です。
トークンが漏れたら、何が起きるか
ここまでの話は、漏れたときにどうなるかを考えると重さが変わります。
ページの中身は、まとめて持ち出せる
トークンがあれば、共有範囲のページを順番にたどって全部取得できます。手作業のコピーと違って、時間もかかりませんし、画面に痕跡も残りません。
共有していたのが1ページでも、その下に子ページがぶら下がっていれば、まとめて対象になります。「1ページしか共有していないから大丈夫」は、階層を数えていないだけのことがあります。
書き込みを許可していると、消される可能性もある
読まれるだけなら情報が出ていくだけですが、書き込みまで許可していると、中身を書き換えられたり、ページをゴミ箱に入れられたりします。
ゴミ箱からは戻せますが、完全に削除されると戻せません。読むだけの用途なら書き込みを外しておく理由は、ここにあります。
気づいたときにやること
漏れたかもしれないと思ったら、順番は決まっています。まず、そのインテグレーションの接続を外します。これで即座に何も取れなくなります。
次に、何が共有されていたかを確認します。接続を外す前に一覧を控えておくと、この確認が楽になります。最後に、書き込みを許可していた場合は、ページが書き換えられていないかを見ます。
新しいトークンを発行して差し替えるのは、そのあとです。先に止める。原因の調査より、止めるほうが優先です。
追加する前に確認する手順
ここからは実際の手順です。新しく連携を足すときに、毎回やると事故が減ります。
1. 何のデータが必要かを言葉にする
先に決めるのはここです。「このデータベースの行を読んで、外部の表に同期する」のように、具体的に書き出します。
書き出すと、要らないものが見えてきます。行を読むだけなら、書き込みは要りません。担当者名を同期しないなら、ユーザー情報も要りません。
この作業を飛ばして「とりあえず全部許可」にすると、あとから絞るのが面倒になります。すでに動いているものを触るのは、誰でも怖いからです。
2. 権限は必要な分だけ許可する
インテグレーションを作る画面で、許可する内容を選びます。読み取り、更新、追加、コメント、ユーザー情報。それぞれ個別に指定できます。
1で書き出した内容に対応するものだけを選んでください。迷ったら外す。足りなければエラーで分かるので、そのときに足せば済みます。
3. 連携用の親ページを決めて、そこだけ共有する
共有はそのページ以下すべてに効きます。だから連携用の親ページを1つ作り、同期したいデータベースをその下に置いて、親だけを共有します。
ワークスペースの上のほうを共有すると、その配下すべてが対象になります。あとから誰かがその下に機密のページを作れば、意識しないまま連携の対象に入ります。
4. トークンの置き場所を決めてから接続する
トークンはパスワードと同じ扱いをします。ソースコードに直接書かず、環境変数かパスワード管理ツールに置いて読み込む形にします。
接続してから置き場所を考えると、動作確認のときに一度コードへ直書きして、そのまま忘れることになります。順番を逆にしないでください。
すでに入れてしまっている場合
これから入れるものより、すでに入っているもののほうが問題です。
まず一覧を出す
ワークスペースの設定から、接続しているインテグレーションの一覧を確認できます。見覚えのないものがあれば、いつ誰が入れたかを確かめます。
使っていないものが残っていることは、よくあります。試しただけのツール、退職した人が入れたもの、乗り換え前のサービス。これらは接続したままだと、権限を持ち続けます。
使っていないものは外す
判断は単純で、いま動いていないなら外します。必要になったらまた繋げばいいだけです。
外すと、そのインテグレーションからは何も取れなくなります。トークンが漏れていたとしても、その時点で無効になります。
権限を絞り直すのは、動作確認とセットで
いま動いているものの権限を絞る場合は、外したあとに実際に動かして確かめます。絞ったことでエラーになる場合は、その権限が必要だったということです。
いきなり本番の自動化で試さず、手元で1回叩いて確認するほうが安全です。
よくある質問（FAQ）
ページを1つしか共有していなければ、それ以外は見えませんか。
ページの中身についてはそのとおりです。ただしメンバーの名前とメールアドレス、他のインテグレーションの名前、ワークスペースの名前は、共有範囲とは関係なく取得できました。これらを見せたくない場合は、インテグレーションを作るときにユーザー情報の許可を外してください。
メールアドレスが見えるのは問題ですか。
用途によります。自分で作った自動化なら実害はありません。外部サービスに登録する形でトークンを渡す場合は、社内の全員のアドレスを渡すことになるので、相手を選んでください。命名規則が分かると、名簿にない人のアドレスも推測できます。
コメントは読まれませんか。
今回試したインテグレーションでは、コメントの取得は拒否されました。403が返り、権限が足りないというメッセージが出ます。ただしこれは許可の設定によるので、コメントの読み取りを許可して作られたものなら読めます。何を許可したかは、作成時の設定で決まります。
誰が書いたかまで分かってしまいますか。
共有したページについては分かります。ページの情報に作成者と最終編集者が記録されていて、その識別子をユーザー一覧で引くと名前になります。議事録や評価メモを共有している場合は、書いた人の名前も一緒に渡ると考えてください。
使っていない連携を外すとどうなりますか。
そのインテグレーションからは何も取得できなくなります。トークンが漏れていたとしても、その時点で無効になります。必要になったら繋ぎ直せばいいので、動いていないものは外しておくほうが安全です。
権限をあとから絞れますか。
絞れますが、動いている自動化が止まる可能性があります。絞ったあとに実際に動かして確認してください。エラーになった権限は必要だったということなので、そこだけ戻します。いきなり本番で試さず、手元で1回叩いて確かめるほうが安全です。
いま入っている連携を、全部言えますか
言えないなら、すでに把握できていない状態です。人数が増えるほど、誰が何を入れたかを追うコストは上がります。管理の仕組みが要る段階に来ているかどうかを、一度確かめてみてください。