3
3
テーマ、知りたいこと
PowerShellのスクリプトファイルの実行は
デフォルトでは出来ないので、セキュリティーレベルを下げるしかないと思います。
このセキュリティーレベルを下げることに対して抵抗があるのですが
どのような運用がいいのでしょうか。
Power Shellのスクリプトファイルを実行できるようにする方法
PowerShellのコマンドで以下等のコマンドを実行する。
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -scope CurrentUser
とローカルで作ったスクリプトや使えるようになる。
Set-ExecutionPolicy
-ExecutionPolicy
実行ポリシー | 説明 |
---|---|
Restricted | すべてスクリプトの実行を禁止 |
AllSigned | すべてのスクリプトに証明書を要求 |
RemoteSigned | インターネットからダウロードしたスクリプトに証明書を要求 |
Unrestricted | すべてのスクリプトの実行を許可 |
-Scope
実行ポリシー | 説明 |
---|---|
Process | 現在のWindows PowerShellプロセスに対して設定された実行ポリシー |
CurrentUser | 現在のユーザに対して設定された実行ポリシー |
LocalMachine | コンピューターのすべてのユーザーに対して設定された実行ポリシー |
UserPolicy | コンピューターの現在のユーザーのグループポリシーによって設定された実行ポリシー |
MachinePolicy | マシングループポリシーによって設定された実行ポリシー |
RemoteSignedの場合
ネットからダウンロードしたファイルは、実行できない。
そのあと、コピーしたファイルも実行できない。
中身を編集して上書き保存すると実行できるようになる。
「インターネットから取得したファイル」というのが
どの程度のファイルなのかは、具体的な定義は私にはまだわかっていません。
証明書をつける方法について
まだ調べてないのでわかりません。
背景
VBScriptが非推奨になったため、代替手段を知りたい。
問題視していること
セキュリティーレベルを下げる場合、使用する端末すべてで上述のコマンドを実行する必要がある。
このセキュリティーレベルを下げることについて説得力のある正当化が私にはできない。
また、そのコマンドを実行していくのも手間がかかるため抵抗がある。
コメントに対して
「調査したことだけ・試したことが記載されていない質問」
「やってほしいことだけ」と言うような感じの指摘が来ました。
何を追記すればいいのかよくわかりませんが
少し調査したことなどを記載します。
指摘には、出来れば、何を追記してほしい。と言う旨記載して頂けると幸いです。
気になる質問をクリップする
クリップした質問は、後からいつでもMYページで確認できます。
またクリップした質問に回答があった際、通知やメールを受け取ることができます。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
回答25件
#1
総合スコア504
投稿2024/01/03 10:59
編集2024/01/05 15:18[香車]東上☆あらし☆海美「
> 問題視していること
> セキュリティーレベルを下げる場合、使用する端末すべてで上述のコマンドを実行する必要がある。
> このセキュリティーレベルを下げることについて説得力のある正当化が私にはできない。
> また、そのコマンドを実行していくのも手間がかかるため抵抗がある。
これは技術的問題というより、組織的な問題『組織での権限が無いのに、決断させられる』だと考えます。
こういう質問は、teratail では、嫌われるようです。
『自分の権限にあわない、無理な仕事をさせられている』と感じているなら、転職をお考えになっては ?
」
回答への修正依頼 スパムと見受けられる内容を含む回答 2024/01/05 17:57
[香車]東上☆あらし☆海美「
ワシの意県は、貴方と異なります。
」
#2
総合スコア85766
投稿2024/01/03 16:34
Windowsユーザーは企業など組織の中だけでなく、自分も回りもITに詳しくない普通の人がショップで買って帰って使うというケースも多いので、デフォルトがRestrictedになっているのだと理解しています。つまり、PowerShellを実行する必要のない人向け。
以下は一般論ですが、
PowerShellを実行する必要のある人は、おおむね、組織の中の人か、IT知識のある個人でしょうから、どちらの場合も必要に応じて緩めて問題ないでしょう。IT知識のある個人なら緩めることによるリスク対策を自分で考える。組織の中の人なら、IT管理部門があるはずなので、その部門がリスク対策を考えて実施する。対策が出来る範囲の所まで緩めれば良いです。全く対策できないなら無理で、PowerShellに限らず、おそらくVBScript実行も駄目でしょう。
もう少しブレークダンして書くと、
・セキュリティーをここまで緩めることで、これこれこういうリスクが発生する
・そのうち、これとこれについては、こういう対策を取れば問題は発生しないはず
・ただし、このリスクについては、現状で簡単に対策できないので、こういう場合にはこういうことが起こってしまう
・緩めることでのメリットはこれこれこういう事が出来るようになる。緩めないとそういうことは出来ない
みたいなことを具体的に説明するのでしょうね。
個別論では、「インターネットからファイルダウンロードし放題。何をインストールするのも自由」というPCと、「業務プログラム専用PCで、PC内の改編は一切出来ない仕組みになっている」というPCで、これに対しての考え方は全く異なるでしょうから、ケースバイケースで考えることになるでしょう。
VBScriptが非推奨になったため、代替手段を知りたい。
これも、ケースバイケースでしょうね。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
#4
総合スコア1506
投稿2024/01/03 21:27
編集2024/01/03 22:281
やらされているというよりか、こちらが提案して採用してもらう立場という感じです。
転職の勧めとか考えていただきありがとうございます。
2
もう少しブレークダンして書くと、
略
みたいなことを具体的に説明するのでしょうね。
そうですね。メリットとデメリットを挙げて採用を、決める権限のある部門に検討してもらうという事になりますね。
個別論では、「インターネットからファイルダウンロードし放題。何をインストールするのも自由」というPCと、「業務プログラム専用PCで、PC内の改編は一切出来ない仕組みになっている」というPCで
これに対しての考え方は全く異なるでしょうから、ケースバイケースで考えることになるでしょう。
私が想定していたPCは、業務用のPCではありますが、許可が下りればネットからダウンロードしたものもインストールはしてもいい。という感じの環境です。
VBScriptが非推奨になったため、代替手段を知りたい。
これも、ケースバイケースでしょうね。
今まで現在の職場で、VBScriptでやっていたものは、インターネットで拾ってきたものとかいうのではなく自作のものです。
具体的には、テキストファイルの置換や、分解、レジストリの修正
この程度でしょうか。
なので、RemoteSignedで、CurrentUserにするのがいいとは思っています。
VBScriptでやっていた理由は、テキストで書かれているので、exeにするよりもソースがなくなる。という事がありえないため。
そして、そのファイル単体で動作するから。というこの2点となります。
もちろん、ケースによっては、ExcelのVBAで出来る場合もあれば
VBScriptで作成困難な時は、VisualStudioのライセンスがあるのでExeを作って対処することもあります。
ただ、ソースの管理さえ出来ていれば、Exeで対処できてしまうわけですので
PowerShellは必須とまでは、言えないと感じています。
なので、セキュリティーレベルを下げてまで、PowerShellに拘る必要はないと考えています。
しかし、MicrosoftからVBScriptの代替がPowerShellだと言われるし
また、PowerShellは色々出来て便利なので
どうにか、それを使えるようにも出来ないものかなと日頃から感じていたので
今回の意見交換を投稿させていただきました。
3
『なぜ UNIX 系 Tools に出来ないか』ぐらいは、説明しないと。『PowerShell でやれ、と言われたから』でいいから。
?無知で申し訳ないですが、UNIX 系 Toolsは、その環境を整備するのにインストールとか結構必要ではないですか?
インストールして環境を整えて使えるようにするという話であれば、pythonでも良いかと思います。
特に、PowerShellでないとだめという理由はありません。
VBScriptの代替と言うなら、便利だし使いたいなぁと、私が感じているだけです。
今まで『どんなことを VBScript でやってきたのか』は、説明しないと。『社外秘で書けません』だと、突っ込んだ話には、ならないと思う。
上述の通り、今まで現在の職場でやってきたのはテキストファイルの変換と分解、あとレジストリ操作くらいでしょうか。
ただ、PowerShellが使えるとなると、もう少しやれることの幅が広がるから便利だと考えています。
しかし、セキュリティーを考えると使えないままの方がいいのかな。とも思ってはいるのですが
それなら、VBScriptの代替にならねえじゃんと思うのですよね。
というような状況なのでPowerShellは、使わないまま
ほかの手段で、対応して行く感じになりそうだな。と思いさみしく感じている次第でございます。
セキュリティー上の問題と言うなら
exeの実行の方が危険だろ。と思うので
vbscriptも残そうよ。と思ってしまいます。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
#5
総合スコア85766
投稿2024/01/04 01:15
私が想定していたPCは、業務用のPCではありますが、許可が下りればネットからダウンロードしたものもインストールはしてもいい。という感じの環境です。
↑こういう書き方をすると、該当する企業は多いでしょうが、
・各ユーザーに管理者権限はあるのか?
・どういったセキュリティーソフトが入っているのか
・ファイルサーバー等でのファイル共有はあるか?
・受信メールの添付ファイルに対してはどういう対策が取られているのか
・申請せず黙ってダウンロードしてexeやvbs等の実行は可能か不可能か
・申請せず黙ってダウンロードしてインストールは可能か不可能か
・申請して厳しい審査でかなり説明しないと通らないのか、所属部署マネージャの(場合によってはザルの)許可があればそれで通っちゃうのか
などなど、色々考えられ、ケースバイケースとしか言いようが無いです。
そもそも現状でどんなリスクがあるのか、PowerShell実行を許可することでどんなリスクが増えるのかですね。
穴のない容器に穴を開けると水が漏れるか漏れないかの違いがありますが、穴がいくつか空いた容器に1つ穴を追加しても、漏れる水の量はほぼ同じ。そのあたりの説明なく「こういう穴を開けても良いか駄目か?」と聞かれても答えようがない。
まずは、「そもそも現状でどんなリスクがあるのか」のリストアップから始めてははどうでしょうか。
PowerShellは色々出来て便利なので
権限設定が分野別で、
・システム参照は出来るが、システム更新は出来ない
・プログラム外とのやりとりは、C:\WindowsやC:\Program Files等以外の普通のファイルの読み書きだけ(プログラム内で計算や文字列処理などは可能)
みたいな設定が出来るといいのですが。
あまりPowerShellの細かい設定を知らないのですが、もしかして出来たりするのかな。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
#6
総合スコア1506
投稿2024/01/04 02:07
編集2024/01/04 02:07そのあたりの説明なく「こういう穴を開けても良いか駄目か?」と聞かれても答えようがない。
PowerShellが、どの程度使われているのか私は知らないので
どんな運用方法があるのか知りたいと思い投稿しました。
どのような、PowerShellを使う運用例があるのか、今だあまりよくわかりませんが
とりあえず、投稿を頂いた内容を踏まえての私の見解としては
Exeを作るのが敷居が高くない環境下では、セキュリティーレベルを下げてまでPowerShellを使う理由はない。
というものです。
まぁ。。。PowerShellとは、ご縁がなかったということでしょうか。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
#7
総合スコア13692
投稿2024/01/05 05:59
?無知で申し訳ないですが、UNIX 系 Toolsは、その環境を整備するのにインストールとか結構必要ではないですか?
そんなことはないです。Windowsのターミナルでubuntu等が使えるWSLのインストール手順はどんどん改良されていて、いまではOfficeを導入するより簡単と言っていいほどです。
これ以外にも、ファイル一本ダウンロードするだけでかなりの範囲の「Unix系ツール」をカバーできるbusyboxというものがあります。ここ最近の私の回答を見ていただければ使い方は分かっていただけると思います。
全てを賄えるわけではありませんが、データファイルの加工等の作業においてはバッチファイルやPowerShellでうんうん唸るよりは断然マシな選択肢だと思います。「レジストリの修正」はちょっと分かりませんが。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
#8
総合スコア85766
投稿2024/01/05 13:26
Exeを作るのが敷居が高くない環境下では、セキュリティーレベルを下げてまでPowerShellを使う理由はない。
というものです。
Powershellのセキュリティー設定を変更することが、果たして、どの程度セキュリティーリスクを高めることになるのかどうか、きちんと考えていますか?
というのが、私の問題提起ですが、別に使わなくて良いのであれば、考えずに使わないというのも、妥当な考えだと思います。
書かれている状況の一部から書かれていない部分まで推測すると、ほとんどセキュリティーリスクに関係なさそうな気がしますが。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
#9
総合スコア85766
投稿2024/01/05 14:19
編集2024/01/05 14:21あと、必要とされる状況がいまいちピンときませんが、恒久的な変更じゃなくて、実行する時だけ一時的にレベルを変更して実行するという例もあるようですね。具体的な方法は何通りかあり。
こういう事も出来るので、「ほとんどセキュリティーリスクに関係なさそうな気がしますが。」ということでもあります。恒久的な変更との差は、例えば「メールで送られてきたps1ファイルをうっかり実行してしまった」時の影響の違いでしょう。ただし、そういうことをやってしまうような人は、「実行してエラーになればこのコマンドを実行してから、再度実行してください」とかメールに書いてあるとその通りやってしまうだろうから、あまり差は無いかと。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
#10
総合スコア1506
投稿2024/01/05 16:06
そんなことはないです。Windowsのターミナルでubuntu等が使えるWSLのインストール手順はどんどん改良されていて、いまではOfficeを導入するより簡単と言っていいほどです。
なるほど。。。私は、まだWSLに手を出していないのですが、簡単になってるんですね。
そういう運用も、ありな気がします。
インストールしていくことに問題なければ。ですが。
これ以外にも、ファイル一本ダウンロードするだけでかなりの範囲の「Unix系ツール」をカバーできるbusyboxというものがあります。ここ最近の私の回答を見ていただければ使い方は分かっていただけると思います。
はい。最近のは見させていただいております。
推してますよね。
Powershellのセキュリティー設定を変更することが、果たして、どの程度セキュリティーリスクを高めることになるのかどうか、きちんと考えていますか?
えっと。セキュリティーレベルをRemoteSignedに下げてPowerShellを使う方が、vbsを使うよりは、セキュリティーリスクが低いという印象はあります。
ただ、それがどんなものなのか、私は正確にしらないので怖がっているという所でしょうか。
あと、必要とされる状況がいまいちピンときませんが、恒久的な変更じゃなくて、実行する時だけ一時的にレベルを変更して実行するという例もあるようですね。具体的な方法は何通りかあり。
そうですね。scopeをプロセスにすれば、一時的にそのプロセスでだけ許可される形になるようですね。
ただし、そういうことをやってしまうような人は、「実行してエラーになればこのコマンドを実行してから、再度実行してください」とかメールに書いてあるとその通りやってしまうだろうから、あまり差は無いかと。
そうですね。実際、各自で勝手にPowerShellのスクリプトファイルを実行できるようにしてしまっている場合もある気がします。
私の見解は、先ほど言った通りではあるんですが
コマンドの説明を見る限りでは、RemoteSignedのCurrentUserでセキュリティー的には問題なさそうではあるんですよね。
ただ、私がPowerShellに対して無知なので、知らないのは怖いという事で設定を変更することが怖い。ということです。
無知というのは、無知ゆえに、コマンドの説明を鵜呑みに出来ない。ということです。
スクリプトファイルをすべて無効にするなら安全な気がするけど
実行できる場合もあるという設定だと、脆弱な部分が増える気がして怖いのです。
しかし、PowerShellが、.Netを使えるスクリプト言語と聞くととても魅力的に聞こえて
使いたくなってしまう自分が居るわけです。
この欲求をどうして抑えるか。もしくは、使える状況にならないかな。と望む次第でございます。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
#11
総合スコア1506
投稿2024/01/08 14:33
編集2024/01/08 14:54https://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q11291492196
知恵袋で、使用例を聞いてみました。
今の所
多分、ByPassで使用しているという使用例を教えて頂きました。
勇者ですね。と今の私には感じられてしまいます。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
#12
総合スコア85766
投稿2024/01/09 02:18
ただ、私がPowerShellに対して無知なので、知らないのは怖いという事で設定を変更することが怖い。ということです。
PowerShellに対して無知でも、ExeやVBSのリスクについては熟知しているのであれば、少し調べればPowerShellについて同様の知識は得られると思います。
そうじゃなくて、VBSスクリプトの実行を許可したり、標準提供でないEXEを実行させることにどんなリスクがあるのかについても考えたことないのであれば、まずはそこからですね。
「Windowsのデフォルト設定を変更しなければセキュリティーは大丈夫」と思っているのであれば間違いです。
調べたことはないですが、グループポリシーとかでVBS実行不可設定は出来そうな気はします。あるいはWSCRIPT.EXE CSCRIPT.EXEの削除という手もあるし。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
#13
総合スコア1506
投稿2024/01/09 13:59
自分が使うだけでも怖いですが、他人も使うとなるとさらに怖いです。
PowerShellに対して無知でも、ExeやVBSのリスクについては熟知しているのであれば、少し調べればPowerShellについて同様の知識は得られると思います。
そうでしょうか。
実際、余り調べてはいないのですが、分からないので投稿しているわけです。
調べる一環です。
もしかして、teratailへの投稿は調べる一環にはならないという事でしょうか。
VBSスクリプトの実行を許可したり、標準提供でないEXEを実行させることにどんなリスクがあるのかについても考えたことないのであれば、まずはそこからですね。
どの程度の危険性があるか、正確には理解していないですが
危険性があることについては、ある程度理解しているつもりです。
もしかして
「VBSスクリプトやEXEを使うことに抵抗はないのに、なぜPowerShellに対して心配しているのか」
と受け止めておられるのでしょうか。
VBSスクリプトやEXEを使うことに抵抗がないわけではなく
それらの危険性があるのは、分かっているからこそ
更にPowerShellに対しても穴をあけることに対して、心配をしていると解釈してもらえると幸いです。
「Windowsのデフォルト設定を変更しなければセキュリティーは大丈夫」と思っているのであれば間違いです。
そうですね。それは間違いですね。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
#14
総合スコア85766
投稿2024/01/10 10:39
実際、余り調べてはいないのですが、分からないので投稿しているわけです。調べる一環です。
もしかして、teratailへの投稿は調べる一環にはならないという事でしょうか。
私が「調べる」と書いたのは、「PowerShellで出来ることを知る」ということです。
もしかして
「VBSスクリプトやEXEを使うことに抵抗はないのに、なぜPowerShellに対して心配しているのか」
と受け止めておられるのでしょうか。
そうですね。玄関全開なのに、裏口だけ厳重な鍵を掛けているみたいな。
VBSスクリプトやEXEを使うことに抵抗がないわけではなく
それらの危険性があるのは、分かっているからこそ
その危険性をどうやってコントロールするかというのがリスク対策です。
更にPowerShellに対しても穴をあけることに対して、心配をしていると解釈してもらえると幸いです。
たしかに、玄関全開でも、裏口の心配をすることは無意味では無いでしょうね。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
#15
総合スコア74
投稿2024/01/10 12:38
編集2024/01/10 12:40聞きたいことが伝わらないもどかしさお察しします・・・
おそらく、VBSは親しんで来たのでだいたい分かっているが非推奨になってしまった。PowerShellが代用手段と聞いたが、デフォルトで実行許可されていないためセキュリティリスクが高いのではないか。でもどの程度のセキュリティリスクなのかは少し調べても分からない。という感じの事ですよね。
どうやらこうだというくらいの事しか知識がありませんが・・・
VBSは、設計が古く、出来る範囲の事は何でも無条件許可です。非推奨となったため、今後バグや脆弱性が見つかっても、放置されるか対応が遅くなると思われます。そのうち、明示的に追加インストールしないと動かなくなったり、完全に動かなくなるでしょう。(セキュリティリスクとなるのであれば、いっそ削除すればリスクはなくなるため。)
PowerShellは、セキュリティという考え方が導入され、むしろ初期設定ではVBSよりも安全です。ただ、VBSよりも柔軟で強力(難しい処理を比較的容易に作成できる。VBSよりも出来る処理内容が増えている)とされており、そういう意味では全て許可とした時のセキュリティリスクはVBSよりは高いでしょう。1段セキュリティを下げた状態は、なんとも言えないと思います。VBSもその気になれば色々出来るので何でも許可するのもセキュリティリスクといえるでしょうし、特定条件下であれば柔軟で強力なPowerShellもセキュリティリスクといえるでしょう。
exeは、その気になれば何でも出来ます。これもリスクでしょう。
WSLは、LinuxのOSをほとんどそのままWindowsと共存させるようなものなので、特別にWindowsから守られているフォルダ以外は、ある意味なんでも出来てしまいます。これまたリスクといえるでしょう。
結局、よく調べ、使ってみて(別途お試し環境を作るとかても良いです。)、理解し、メリットとリスクを比較し、許容出来る範囲を決め、使うしかないと思います。
個人的には、VBS, exeの編集・実行が許されている環境であれば、PowerShellのセキュリティを一段下げ、署名なしコードのローカル実行を許可しても、exe実行よりはリスクは低いと考え、使うことにすると思います。
ちなみに、典型的なよくあるウイルスは、偽サイトやメールから懸賞当選や本物の客先を装ったりして、ファイル(exe, PowerShell, VBS, Excelマクロ等)をダウンロードするよう誘導し、実行させます。
例えば、将来、明示的にユーザが実行するつもりがないのに勝手にVBSを実行出来るようになるようなバグが発見され、それが修正されずに放置されていた場合、そのPCはVBSをダウンロードした時点で感染します。VBSが無効だったら助かった、なんて事があるかもしれません。これがPowerShellだったら、バグが発見されたけど、1ヶ月以内に修正され助かった、とかもあるかもしれません。(あくまでPowerShellが有利に見えるよう書いてるだけで、実際はケースバイケースです。)
ご参考になれば幸いです。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
#16
総合スコア1506
投稿2024/01/10 13:15
編集2024/01/10 13:54そうですね。玄関全開なのに、裏口だけ厳重な鍵を掛けているみたいな。
たしかに、玄関全開でも、裏口の心配をすることは無意味では無いでしょうね。
otnさんは、そういう感覚だという事でしょうか。
見解ありがとうございます。
私の感覚では、鍵のある玄関があるだけの社員の家に
鍵があるかないかよくわからない入り口を作るようなもの。
という所です。
当然、玄関も鍵をあければ侵入できますが
よくわからない入り口は、鍵がある玄関の存在よりも怖いとは感じます。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
#17
総合スコア1506
投稿2024/01/10 13:47
編集2024/01/10 13:52#15
投稿ありがとうございます。
VBSは親しんで来たのでだいたい分かっているが非推奨になってしまった。PowerShellが代用手段と聞いたが、デフォルトで実行許可されていないためセキュリティリスクが高いのではないか。でもどの程度のセキュリティリスクなのかは少し調べても分からない。という感じの事ですよね。
PowerShellも何となくはわかるけれど、設定変更して使う許可を得るために職場の管理者?に胸を張って説明する自信がない。という所です。
その為、職場で使えないという状況です。
結局、よく調べ、使ってみて(別途お試し環境を作るとかても良いです。)、理解し、メリットとリスクを比較し、許容出来る範囲を決め、使うしかないと思います。
私の今の職場では、PowerShellを使っていいのかどうかがわからない状況です。
多分、誰も必要としていないから検討もしていないという状況だと思います。
ただ、私としては今の職場で使えるようになれば、ExeやVBAやVBSの代わりに使ってみて
勉強したいと考えています。
当然、仕事のためにも使う事を想定していますが、結局は私の自分勝手だし
PowerShellが必須というわけでもないので
許可を求めることに対して、腰が引けているという所です。
職場の端末の多くがRemoteSignedの設定にしてもらえるなら、それが一番ありがたいのですが
実際の色々な運用例から鑑み、この程度の設定であれば要求してもいい。というラインを知りたいのです。
そしてあわよくば職場で使いたいのです。
家のPCでお試しの環境を作って勉強することは出来ますが職場で使いたいという所です。
ご参考になれば幸いです。
他者の見解を聞きたくて意見交換を投稿しましたので、見解ありがたいです。
参考になります。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
#18
総合スコア85766
投稿2024/01/10 14:50
otnさんは、そういう感覚だという事でしょうか。
見解ありがとうございます。
そちらの状況が全く不明なので、「玄関全開」というのは、
「ユーザーに管理者権限もあり、VBScriptもEXEもダウンロードし放題、インストールし放題、自作し放題」を想定していました。なんとなく、VBSスクリプトを自由に作って自由に実行しているのかなと。
想定が違うなら、認識も変わってきます。
私の感覚では、鍵のある玄関があるだけの社員の家に
「鍵がある」という状態ということは、上記の想定が違っていて、
「セキュリティー管理部門がガチガチに固めていて、非標準のプログラムを実行する許可を得るだけでも一苦労。自作VBScriptスクリプトの実行許可も大変だった」
みたいな状況なのでしょうか?であれば、確かに、
鍵があるかないかよくわからない入り口を作るようなもの。
という印象なのかも知れませんね。
と思ったけど、ただ、そこまでガチガチなら、PowerShellのセキュリティーレベルがどうであれあまり関係ない気もしますね。
やっぱり、今の状況が分からないと、あまり実のある意見交換はできない気がします。
#5 にいろんなパターンを挙げてみたのですが。
状況から独立した一般論で言うと、レベルを下げるかどうかは、先に書いた、こういう違いでしょうか。
例えば「メールで送られてきたps1ファイルをうっかり実行してしまった」時の影響の違いでしょう。ただし、そういうことをやってしまうような人は、「実行してエラーになればこのコマンドを実行してから、再度実行してください」とかメールに書いてあるとその通りやってしまうだろう
と書いたけど、添付ファイルの中味を見てフィルタリングしていれば、こういうことにはならないので、状況依存か。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
#19
総合スコア1506
投稿2024/01/10 15:22
「ユーザーに管理者権限もあり、VBScriptもEXEもダウンロードし放題、インストールし放題、自作し放題」を想定していました。
今の職場は、ダウンロードは出来ますが、インストールは許可が必要となっているという感じで
しかし、インストールは勝手にも出来る。という感じですね。
性善説に従った環境です。
環境的には、その想定であってます。
私の感覚では、鍵のある玄関があるだけの社員の家に
「鍵がある」という状態ということは、上記の想定が違っていて、
「セキュリティー管理部門がガチガチに固めていて、非標準のプログラムを実行する許可を得るだけでも一苦労。自作VBScriptスクリプトの実行許可も大変だった」
みたいな状況なのでしょうか?
いえ、鍵があると言っても、管理部門が鍵を持ってるのではなく社員個人個人が鍵を持ってる状態という感じです。
(社員の家という例なので、その家の本人は鍵もってます。)
個人が実行しなければ(鍵を開けなければ)勝手には悪さはされない。という印象ということです。
exeとかvbsなら、実行に慎重になるかもしれないけど
ps1とか、一般にはよくわからない拡張子だと勝手に実行してしまう人もいるんじゃないか。
と心配したりするのもあったり
PowerShellは、どの程度意図しない実行が起こりえるのかわからないという心配もある。ということです。
#5
にいろんなパターンを挙げてみたのですが。
セキュリティーソフトの確認など色々書いてあったので
それは答えるのに抵抗があったので、詳細を述べるのは控える形になりました。
何にせよ
個人が鍵を持っていて、自由に実行できる感じではあるんですが
ルール的には、勝手にダウンロードしたものを使っていいわけではなく
許可を得て使う形なわけなので
穴をあけるのも許可を得る必要があると考えています。
※実際には、許可が必要だなんて聞いてませんが、私の常識的に考えて必要だと思っています。
そして、説得力のある許可を得る説明が思いつかない。という所です。
そもそもPowerShell必要ないので。
なので、運用例を聞けば
少しは、足しになるかなと思って、投稿した次第です。
PowerShell使いたいので。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
#20
総合スコア74
投稿2024/01/10 16:31
編集2024/01/10 16:36微妙なラインですが、PowerShellのセキュリティ設定を一段下げる理由が弱いのであれば、さらに非推奨化が進み「VBSは明示的にインストールしないと使えない」、という状況を待つ、とかでしょうか。
私の感触では、Linuxのシェルスクリプト(bash等)のWindows版と捉えていて、シェルスクリプト自体にはセキュリティの概念は特に無いので(Linux自体にファイルのアクセス権とかはありますが)、特に気にせず使えばいいんじゃない? むしろ標準でセキュリティの概念があるだけより安全では?と直感的には感じます。(実際は、Windowsの方が攻撃しやすいとかで、全く同リスクとは言えないと思いますが。)
社内全体のアレルギーが強いとか、リテラシーが低いとかの感触がおありなら、それに合わせるか、彼らのレベルで安心できるくらい情報を集め、体感することで説明が出来るのではと思います。社内への説明となると本当にケースバイケース過ぎて、ご自分で納得出来るまで調べて使うしかないと思います。
自分の周りでは、OS標準で付いてる物だから使っていいと解釈して、WSL派、まだVBSとバッチファイルで十分派、何も使わない(使えない)派の三派閥でしょうかね。私は個人的にVBS非推奨化を受けて新規にはPowerShellを使い始めています。バッチファイル、PowerShell、WSLの併用です。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
#21
総合スコア1506
投稿2024/01/10 16:56
編集2024/01/10 17:01知恵袋の方で使用例の回答がありました。バッチを経由する形ですが、設定を変えずにPowerShellのスクリプトファイルが使えるらしいです。
知りませんでした。
powershell -NoProfile -ExecutionPolicy RemoteSigned .\hoge.ps1
社内への説明となると本当にケースバイケース過ぎて、ご自分で納得出来るまで調べて使うしかないと思います。
とりあえず、全く聞いてもなかったのでひとまず聞いてみます。
少なくとも
端末の設定変えないバッチ経由でなら使っても問題なさそうな気がするので、使えそうな気がしてきました。
ただ、セキュリティの設定は、そのままの方が良い印象が強くなってしまいました。
自分の周りでは、OS標準で付いてる物だから使っていいと解釈して、WSL派、まだVBSとバッチファイルで十分派、何も使わない(使えない)派の三派閥でしょうかね。私は個人的にVBS非推奨化を受けて新規にはPowerShellを使い始めています。バッチファイル、PowerShell、WSLの併用です。
使ってるんですね。
私も、バッチファイルから呼び出す形で使っていってみようかなという気持ちになってきました。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
#22
総合スコア85766
投稿2024/01/13 11:58
powershell -NoProfile -ExecutionPolicy RemoteSigned .\hoge.ps1
それについては、#9 で、
恒久的な変更じゃなくて、実行する時だけ一時的にレベルを変更して実行するという例もあるようですね。具体的な方法は何通りかあり。
と言及したつもりでしたが、伝わってなかったのですね。ちゃんと書けば良かった。失礼しました。
なるほど、これが伝わってないのに、伝わってると思った上で以降を書いてたので、食い違いが続いている原因だったのかも知れません。
上記コマンドを認識いただいた上で改めて書くと、
あなたが検討しているのは、「PowerShellスクリプトを使わせるか使わせないか」ではなくて、「Powershellスクリプトを実行するときに、powershell -file ~~.ps1
で実行できるようにするか、今のままpowershell -ExecutionPolicy ~~~~ ~~.ps1
と書かないと実行できないままにするか」ですよね?
前者の検討だと、Powershell.exeを削除するとかの検討になります。
後者の検討での2パターンの差は確かにゼロでは無いのですが、
・この差は大きいので、いまのままの実行ポリシー設定にしておくべき
・差は誤差の範囲なので、実行ポリシー設定を変更しても問題ない
のどちらに近い考えを持つかは、現状のセキュリティー状況次第だろう。というのが、言いたかったことです。
#9で、その記述の前に「あと、必要とされる状況がいまいちピンときませんが、」と書いたのは、
「こんな実行方法を認めるのならばレベル変更しちゃえば良いのでは?」と私が思っているからです。まあこれは私見なので、同意してもらわなくてもいいです。
個人が鍵を持っていて、自由に実行できる感じではあるんですが
ルール的には、勝手にダウンロードしたものを使っていいわけではなく
許可を得て使う形なわけなので
穴をあけるのも許可を得る必要があると考えています。
※実際には、許可が必要だなんて聞いてませんが、私の常識的に考えて必要だと思っています。
のあたりが微妙ですが、セキュリティーポリシー変更に許可が要ると思うのなら、コマンドラインで今一時的にだけポリシーを変更するのにも許可が要るのでしょうね。効果は同じなので。
まあ、「ソフトのインストール」と「ソフトをインストールせずの実行」の違いと考えて、もし、ルールが、「インストールは許可が要るが、インストールしない実行は許可不要」ならそれでいいですかね。「非標準のプログラム実行はインストールしない場合でも許可が必要」なら必要かと。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
#23
総合スコア7918
投稿2024/01/26 07:04
あくまでもスクリプトファイルの実行に関してのものなので、スクリプトファイルに記載されているコードには概ね影響しないことは認識しておいたほうがいいです。
スクリプトの内容次第なところはありますが、簡単なものしか使わないのであれば、
cmd
1powershell .\script.ps1
だとポリシーエラーになるけど
cmd
1type .\script.ps1 | powershell
だとスクリプトの内容を実行できてしまいます。
許可申請など手間がかかるのであれば、設定はデフォルトのままでバッチファイルなどからこれで実行でもいい気はする。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
#24
総合スコア7
投稿2024/02/20 14:06
結局、リスクは「可能性」の話なので、「いかにそれを軽減するか」ということを考えることが大事だと思います。
質問者様がどこまでの権限をお持ちなのかわからないのですが、情報提供としてお伝えします。
「RemoteSigned」にするのに懸念があるのであれば、安全度の高い「AllSigned」にする手があります。
これを利用する場合は、全ps1スクリプトに証明書でコード署名をして、実行端末に証明書を配布する必要があります。
全社的に配布するとなると信頼できる証明書を作り、ADから証明書を配布して、毎度スクリプトに署名することになるのでかなりの手間にはなると思います。
あるいは、別の方法でセキュリティレベルが上がるならそれも手だと思います。
メールのセキュリティソフトで危ないファイルを駆除したり、EDRなどで実行時にキャッチできるようにするなどの手があると思います。
万一インシデントが起きたとしても、きちんと監査できていれば事後の責任を果たすことはできると思いますので、PC操作/動作ログ取得ソフトなども検討の余地があるでしょう。
もしくは、すでに導入されているセキュリティソフトにPowerShellスクリプトの脅威を防御する機能があるかもしれませんので、それをお調べになるのもよいかと思います。
Microsoftを見ていると「PowerShellをどんどん活用していこう」という方針に見えますので、安全性を担保しながら便利なものを享受していけるように、いろいろ工夫していく、ということが大事なのではないかと思います。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
#25
総合スコア1
投稿2024/02/29 06:12
ドキュメント ソース マネージャー (または Windows ソース マネージャー) で、右クリックして、[PowerShell の実行] 機能を選択します。 」)、脚本を書き、その後会議を中止しました。https://www.blikai.com/blog/projects/how-does-the-oscilloscope-s-x-y-display-work
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。