make SaaS

make 管理運用の話：Connection権限管理

  • 投稿日

この記事は「make Advent Calendar 2024」21日目の記事です。

このアドベントカレンダーについて

このアドベントカレンダーは25日間でIPaaS製品の「make」について使い方や、実践を学べる連続ブログ企画です。

「おかしん」「ばるす」「たにあん」の3名がリレー形式でお届けします。

25日間のスケジュールは以下の通りです。

日付内容担当
12/1話題のIPaaS製品「make」とはおかしん
12/2makeで作ってみたScenario紹介ばるす
12/3make 基本操作編 機能紹介：Organizationたにあん
12/4make 基本操作編 機能紹介：Scenario、Templateおかしん
12/5make 基本操作編 機能紹介：Connectionsばるす
12/6make 基本操作編 機能紹介：Webhooksたにあん
12/7make 基本操作編 機能紹介：DataStores、DataStructuresおかしん
12/8make 基本操作編 機能紹介：Devicesばるす
12/9make 基本操作編 機能紹介：Functionsたにあん
12/10make 基本操作編 機能紹介：CustomAppsおかしん
12/11make 基本操作編 機能紹介：Flow Control,Tools,Text parserばるす
12/12make ドキュメント動線の話：ResourceHubたにあん
12/13make 検証：Make Bridgeおかしん
12/14make 検証：Make REST APIばるす
12/15make 検証：AI Searchたにあん
12/16make Community Hub：Overviewおかしん
12/17make Community Hub：Academy Courses,Blog Articlesばるす
12/18make Community Hub：Showcase,CustomAppsたにあん
12/19makeの管理運用の話：Github連携おかしん
12/20makeの管理運用の話：実行ログと再実行と停止中リクエスト滞留ばるす
12/21makeの管理運用の話：Connection権限管理たにあん
12/22makeで作ってみた事例：（未定）おかしん
12/23makeで作ってみた事例：（未定）ばるす
12/24makeで作ってみた事例：（未定）たにあん
12/25makeの総論を語るばるす

はじめに

どうもたにあんです。今日はConnectionsの権限管理のお話です。が、権限管理といいつつ、Connectionsの管理について色々書きます。ベストプラクティスとかいうやつかもしれません、知らんけど。

「Connectionsってなんやねん！」ってお方は、Connectionsの機能をまとめた記事を過去に公開しておりますので、よろしければご覧ください。

make 基本操作編 機能紹介：Connections
この記事は「make Advent Calendar 2024」5日目の記事です。 このアドベントカレンダーに…
blog.cloudnative.co.jp

Connectionsが何かをざっくり説明しておくと、make以外のサービスと連携するときの認証情報です。

Connections管理の要点

細かい説明は一旦さておき、要点としては以下の3つと考えています。それぞれmakeの仕様を踏まえて説明していきます。

  1. 効果的な命名規則を決めよう
  2. ConnectionsはTeamで制御しよう
  3. 定期的に見直しを実施しよう

効果的な命名規則を決めよう

もっと雑に表現すれば「わかりやすい名前で作成しましょうね〜」です。この記事を読んでくださっているほとんどの方には当たり前の話かもしれません。

余談ですが、適当に名称をつけた結果、自分で作ったConnectionsでさえどれを利用しているのか分からない状態になっています。最悪です。（アドベントカレンダー終わったら全消しします。）

本題で、この話をするにはConnectionsの管理画面の話をする必要があります。

一見、良さそうに思えるかもしれませんが、不便に感じる点がいくつかあります。

  • どのScenarioで利用されているか分からないこと
  • 誰が作成者か分からないこと（モザイク部分は認証に利用されているアカウント名）
    • Audit Logsを見ればわかる（面倒）
  • ソートができないこと
  • 検索にはConnectionsの名称のみ検索可であること

最後の項目が思っているよりキツいです。20〜30個くらいであればギリセーフ。それより多くなってきたら正直厳しいと思います。おそらくConnectionsの画面はみたくなくなります。

なので、わかりやすい名前をつけましょうね、というお話でした。あくまで2024/12/21時点での話なので、今後改善されるかもしれませんが、いずれにしても明瞭な名称をつけるに越したことはないです。

最後に命名規則の例を載せておきます。

命名規則の例
  • 命名規則の例 基本的な命名パターン [サービス名][アカウント情報][用途] OAuth方式の場合 アカウント情報を含めることが重要です：
    • Gmail_yamada_通知用
    • Slack_support_お問い合わせ転送
    • GoogleDrive_marketing_データ保存
    • Notion_admin_案件管理
    この命名により：
    • 誰のアカウントで連携しているか明確
    • アカウント所有者の退職時の引き継ぎが容易
    • 権限の範囲が把握しやすい
    APIキー方式の場合 使用しているボットやサービスアカウントの情報を含めます：
    • ChatGPT_Support-Bot_FAQ応答
    • Slack_Notification-Bot_アラート通知
    • AWS_Backup-Service_データ保存
    • GitHub_Deploy-Bot_自動デプロイ
    この命名により：
    • どのサービスアカウントのAPIキーを使用しているか明確
    • APIキーの更新時に影響範囲が把握しやすい
    • 料金プランやクォータ管理が容易
    命名のその他のポイント
    1. 日本語/英語の統一
      • 全て日本語：Slack_カスタマーサポート_問い合わせ対応
      • 全て英語：Slack_Customer-Support_Inquiry
    2. 区切り文字の統一
      • アンダースコア：Slack_Support_Notification
      • ハイフン：Slack-Support-Notification ※チーム内で統一することが重要
    3. プロジェクトやチーム別の接頭辞
      • PRJ1_Slack_Support_Alert
      • SALES_Gmail_Team_Newsletter
      • MKTG_sheets_Admin_Report
    4. 環境別の識別（開発/検証/本番）
      • DEV_Slack_Test-Bot_Debug
      • STG_Slack_Alert-Bot_Test
      • PROD_Slack_Alert-Bot_Live
    良い例・悪い例 良い例：
    • Gmail_Support-Team_Customer-Inquiry
    • Slack_Alert-Bot_System-Monitor
    • Notion_Marketing-Admin_Content-Calendar
    悪い例と理由：
    • Gmail1（情報が不足）
    • Slack通知用（アカウント情報がない）
    • NotionConnection（用途が不明）
    • Test（全ての情報が欠落）

ConnectionsはTeamで制御しよう

「なんの話？」となった人もいるかもしれません。私は少なくとも権限管理どうなってん…？ってなりました。これを理解するには以下の3要素の理解が必要だと思います。

  1. ConnectionsはTeam単位で管理されること
  2. Usersに割り当てられているTeam Roleによって権限が異なること
  3. 作成されたConnectionsはTeam内で再利用可能なこと

細かい話なんでさっといきまーす。

まず、ConnectionsはTeam単位で管理されます。ただし、Teamを複数作成することができるプランはTeamとEnterpriseのみです。

そして2つ目、Teamにユーザーを追加するとき、Role（いわゆる権限）を割り当てることになります。Roleの内、以下3つのいずれかのRoleを割り当てられたユーザーのみ、Connectionsの作成や削除が可能になります。

  • Team Admin
  • Team Member
  • Team Restricted Member

最後に、作成されたConnectionsを利用できるユーザーは、以下2つの条件を満たしたユーザーです。

  • あるConnectionsが管理されているTeamに参加していること
  • Team Admin / Member / Restricted MemberのいずれかのRoleを割り当てられていること

そのため、例えば企業・組織の中で情報システム部以外のメンバーには利用されたくないようなサービスがあったときには、当該部署のメンバーのみ参加したTeamを作成した上で、Connectionsを作成すると良いということになります。

以上で「ConnectionsはTeamで制御しましょう」というお話でした。

TeamとRoleの詳細については、3日目の記事にありますので、よろしければご覧ください。

make 基本操作編 機能紹介：Organization
この記事は「make Advent Calendar 2024」3日目の記事です。 このアドベントカレンダーに…
blog.cloudnative.co.jp

定期的に見直しを実施しよう

当たり前っちゃ当たり前なんですが、システム管理者でちゃーんとログ確認してますっていう方々も多くはないでしょう（偏見）。Connectionsで確認するポイントをまとめておきます。

  • 定期的にConnectionsの接続検証を実施しましょう
    • 月1とかでいいと思います。
    • 手動でやってられないのでAPIを使いましょう。
  • Connectionsのエラーをキャッチしましょう
    • 一応Scenarioで失敗したらメール通知は来ます。そんなのみてられないです。
    • APIを使いましょう
  • Team RoleとConnectionsの管理場所が適切か、棚卸ししましょう
    • Connectionsの「効果的な命名規則を決めよう」で書いた通り、Web画面をいちいちみてられないです。
    • APIを（ry

おわりに

冒頭でベストプラクティスとかいいつつ、各組織で最適な運用は何か考えてみてください。ベストなんてなかったんや。

さて、あしたからは作ってみたのシリーズです。なんだかんだこの1ヶ月弱で相当makeには強くなったんじゃないかと思います。3日おきに記事を書くの辛かったですが、最後と思うとなんだか寂しい気もします。

というわけで、これまでの細々した内容から打って変わって実践編って感じなので、ラストスパートお楽しみに！

では、また3日後。

たにあん

2024年12月運用支援サービス（仮）のメンバーとして入社。
とりあえずやってみるをモットーにおしごとをしています。
好きなものは甘いもの。
嫌いなものは甘いものを食べていない時間。

記事一覧