Learn all the possibilites of Box and sign up for our new "Optimizing with Box" course. 他のユーザーが使用するのは規約違反です。, Microsoft も Office 365契約者の利用状況を定期的に確認しているようですし、あとは ご自身の判断でしょうけど、、、いくらなんでも、1名分の料金だけで 5人で使おうとするのは悪質だと思いますし、コスト削減したいのは どこの企業も同じですよ。, また、各デバイスでアプリが同時に起動できるのは、Office 365がそういう仕様が売りなので当然です。 Office 365 Proplus subscription サービスのライセンス】, この中の「ユーザ単位の Microsoft Office ライセンス」が該当すると思います。, このスレッドはロックされています。質問をフォローすることや役に立つと投票することはできますが、このスレッドに返信することはできません。. Boxアカウントにチームメンバー (およびビジネスパートナー) を追加する方法 ; 関連するフォルダに複数ユーザーをグループで一度に追加する方法 内部ユーザー (管理対象ユーザー) の追加. Office 365 Businessは1サブスクリプション(¥900 ユーザー/月)で5台のPCにインストールできると思いますが、これを5人で利用しては規約違反などになりますでしょうか。, http://licensecounter.jp/office365/faq/case08.html, にありましたが、PC共有しているわけではなくて、ちょっと状況が違うと思いましたので質問させていただきました。, 実際、自分に関しては5台のPCを使っていて、ダウンロードした実行ファイルを5台のPCで実行してインストールして、普通に使えました。, 黙って1サブスクリプションを5人で使っても良いのかもしれませんが、問題ないのか問題あるのか、規約などで明記されているものがあれば知りたいです。, ユーザーって書いてあるのだから 5人なら5ユーザーですよね、流石にそれは分かると思うのですが、、、, https://products.office.com/ja-jp/business/compare-office-365-for-business-plans, フィードバックをお送りいただきありがとうございます。今後のサイト改善に役立てて参ります。, Office 365ライセンスが「ユーザーライセンス契約」であると承知した上で購入しているのですから、「どこにも書いていない」は通らないと思います。, 一高見沢さんのアカウントで5デバイスにインストールしたのなら、その5デバイスの Office は、一高見沢さん以外のユーザーは使用できません。 先日の「共有アカウント、ダメゼッタイ!」というツイートの反響が大きかったので、もう少し具体的にまとめてみました。, 「共有アカウントはダメ絶対!」という認識は、もっと一般常識として広まってほしい気持ちはある。・パスワード管理がザル・監査ログが意味をなさなくなる・MFA運用できない・SSO導入の際の足枷などなど、セキュリティ的に致命的な問題だらけ。ライセンス的にもNGなことが多いし。, エンジニアや情シスに限らず、システム利用者の方々にも知っておいてほしい内容なので、社内での共有アカウント撲滅に向けての啓蒙材料としてぜひご活用ください。, 各種クラウドサービスやシステムに対話型ログインするアカウントのうち、アカウントと利用者が「"1対1"ではなく"1対多"で利用しているアカウント」のことを、本エントリでは「共有アカウント」と定義します。※API用のアカウントなど、個人には紐付かないものの共有して使用する アカウントについては「システム用アカウント」として後ほど説明します, 1.ライセンスの問題有償のソフトウェアやクラウドサービスはもちろん、無償のサービスにおいても一般的にはアカウントの共有は認められていないことが多いです。知的財産権を侵害して違法となるケースもありますので、利用するサービスの規約をきちんと確認しましょう。, 2.制約の問題金融関係のシステムなどではそもそも同時ログインができないように排他制御がかかっていたりしますが、そうでないシステムの方が圧倒的に多いです。「複数人で同時に使えそうだから、とりあえずアカウントを共有して使おう」といった運用がスタートしてしまい、後から監査で指摘が入ったり、システム的な制限がかかってしまい、業務に支障が発生するといったパターンもあります。, よく見かけるケースが、「Gmail(G Suite)のアカウントを共有して、カスタマーサポートの送受信メールを全員が見れるようにする」といった運用ですが、Gmail(G Suite)アカウントはある程度のユーザーが同時ログインして使用しているとアカウントが強制的にロックされます。, 人数が少ないうちはGmailの共有でカスタマサポートが成り立っていたのが、規模が大きくなるとアカウントが度々ロックされるようになり業務が成り立たなくなるといった事態になりかねません。このようなケースでは、「使えるからこれでいいや」ではなく、メーリングリストやメール共有ツールの導入など別の仕組みを検討すべきです。, 3.セキュリティの問題これが一番深刻な問題なので、いくつか具体例を挙げて掘り下げてみます。, 共有アカウントはパスワード固定で運用されていることがほとんどです。パスワードを変える度に共有メンバーに新しいパスワードを周知したり、手間がかかるので頻繁にパスワードを変更することもしないでしょう。, パスワード固定の運用は、利用者がパスワードを記憶していたり控えていれば退職後もクラウドサービスにログインできてしまうといったリスクがあります。「退職者が発生した場合は、都度パスワードを変更する」という運用を徹底しようとしても、アカウントを共有している人数が増えるほど、誰とパスワードを共有していたのか分からなくなり、運用が破綻していきます。パスワードを共有した人が、さらに他の人にパスワードを共有している可能性もあるでしょう。パスワードは共有されるほど認証要素としての価値は下がっていくことを認識しておきましょう。, 各種システムでは、「どのアカウントが、いつどのような操作を行ったのか」といった監査ログを取得しています。共有アカウントを使われてしまうと、監査ログから利用者を特定することが困難になります。, たまに見かけるのが、プロダクトの本番環境で作業するための特権アカウントをエンジニア全員で共有しているパターンです。どの利用者の操作も同じアカウントでログが記録されてしまうので、ログからの利用者の判別が不可能になります。酷い場合だと、システムのバックグラウンドで動作するアカウントとオペレーションで使用するアカウントが同じで、バッチ処理なのかオペレーションなのかの判別もできなかったりします。, インシデントが発生した際の追跡はもちろんですが、そうでなくても内部統制や監査などでシステムの監査ログをチェックされることはあります。監査ログを見ても誰がオペレーションしているのか分からないような状況であれば、統制が効いている環境とはとてもいえません。「IDはidentificationであり、識別するための情報」ということを認識し、特権アカウントについても利用者個々に発行しましょう。, ログの話からは逸れますが、普段使いのアカウントに特権を付与することは、オペミスによるデータ損失や、一般権限ユーザーとの挙動の変化に気付けないという問題もあったりするので、特権作業用のアカウントを管理者ごとに発行し、特権作業が必要な時のみ使用するような運用が好ましいです。, 不正ログイン対策として、アカウントの認証にID&パスワード以外の要素を必須とする多要素認証が一般的になりつつあります。携帯電話のSMSやワンタイムパスワードを第2の要素として用いることが多いですが、共有アカウントが存在する場合は多要素認証の運用が非常に困難になります。, 例えば携帯電話のSMSを第2要素として用いた場合、共有アカウントを利用するメンバー間でその携帯電話を常に触れる状態にする必要があります。物理的に離れた場所にいればシステムにログインできませんし、多要素認証に使用している携帯電話自体を共有することで、認証要素としての価値は下がります。携帯電話や物理的なトークンならまだしも、生体認証の場合は共有すらできません。, クラウドサービスの業務利用が増えてきている昨今、多要素認証の導入は当たり前になりつつあります。「社内のセキュリティ強化のために、多要素認証を必須にする」となった途端に運用が破綻したり、逆にいつまで経っても多要素認証が導入できなくなるといったリスクがあることを認識しておきましょう。, 多要素認証の話とも関連しますが、セキュリティと利便性の向上のためにIdPやIDaaSを導入してSSO環境を構築する企業が増えてきています。※IdP・IDaaS・SSOに関する説明は、こちらのエントリに簡単に まとめていますので、よければ参考にしてください, SSO環境では、利用者のアカウントと各クラウドサービスのアカウントが1対1で紐づくことが前提となります。共有アカウントが存在する場合は、共有アカウントでログインするために、「普段使っているユーザーからログアウトして、共有アカウントでログインし直す」といった手間が発生します。システムによってはデスクトップログインのアカウントまで各サービスのIDが紐付いている場合もありますし、異なるアカウントで同時に複数のセッションを張ることができない場合もあります。, 共有アカウントが存在する場合は、SSOを導入する前に各クラウドサービスの共有アカウントを全部組み解き、1対1に紐付ける必要があります。これは共有アカウントとクラウドサービスの数が多いほど、非常にパワーがかかる作業となります。, 業務利用するクラウドサービスが増え、SSOの導入が急務となる企業も多いと思いますので、最初から共有アカウントありきの運用を構築しないように配慮しておきましょう。, 共有アカウントを撲滅したいところですが、完全にゼロにするのは難しい局面もあります。, ・システム用アカウント各サービスのAPI連携用のアカウントなど、バックグラウンドで動作するアカウントに従業員の個人アカウントを設定してしまうと、退職時にアカウントを停止した際に不具合が発生してしまいます。こういった「普段使いではない、システムやサービスのバックグラウンド用のアカウント」は、システムごとに専用のアカウントを発行し、そちらで設定しておくのが好ましいです。そのアカウントのパスワードも、必要最小限のメンバーのみに伝えて管理しておくようにしましょう。(GitHubにAPIトークンやパスワードを載せないようにも要注意)さらにセキュリティレベルを上げて管理したいのであれば、システム用アカウントにもトークン等の物理的な多要素認証を設定し、社内で厳密に保管しておくなどの方法も考えられます。, ・特権アカウントを複数発行できないサービスの特権アカウントサービスによっては、「特権アカウントはひとつしか発行できない」といった残念な仕様もあります。本来は利用者ごとにアカウントを発行し、適切な権限を付与して運用すべきですが、それができないパターンです。かといって特権アカウントのパスワードを一人しか知らない状況も可用性が無く危険なので、実際にオペレーションを行うメンバー間でのみ共有し、パスワード管理を厳密に行うしかありません。, こういった「どうしようもない特権アカウント」のパスワードを共有しない手段として、「1PasswordやLastPassといったパスワード管理ツールを会社として導入し、パスワードを隠蔽しつつパスワード管理ツール経由で各種システムにオペレータがログインする」といった策も考えられます。, 上記以外にも様々な事情で無くすことが難しい共有アカウントがあるかもしれませんが、大切なのは「アカウント共有に潜んでいるリスクを認識し、リスク許容できるか判断した上で、アカウントの共有を許可するかどうか」の評価を実施することだと思います。とりあえず脳死で共有はやめましょう。, 共有アカウントの問題点についてつらつらと述べてきましたが、なぜアカウントの共有といった運用が発生してしまうのでしょうか。みんな悪いと分かっていて使っている訳ではありません。リスクに気付いていないだけで、コスト・利便性を重視し、事業の為によかれと思ってアカウントを共有してしまっているパターンも多いと思います。そういったケースを減らすためにも、アカウントの共有に関するリスクを啓蒙していく必要があります。, このクラウド全盛時代、様々なクラウドサービスを利用するシーンが増えて、アカウント認証や管理が今後より厳密になっていくのは間違いありません。後々に自分たちの首を絞めることにならないように、はじめから正しくアカウントを管理してサービスを活用していきましょう。, Google Form, Slack, Zapier, Trelloで作る簡易ヘルプデ….