  |
はてなキーワード: 副責とは
持続化給付金「申請サポート会場」を訪ねて |君嶋ちか子|神奈川県会議員
この方が疑問に感じておられる事を、可能な範囲で回答してみたいと思います
⬛⬛⬛
●「状況を伺いたい」というと、手に消毒液を掛けられ、外で７~８分待たされました。ようやく出てきた人に名前と用件を伝えると、また「お待ちください」と引き続き外で。
３人目の取次の方は、「外でなら話せます」と。
「はあ？その理由は？」「入場すると感染した場合の追跡が可能なように登録しなければいけません」との回答。
私は登録することを認め、ようやく会場に入れてもらえました。
最初の窓口で、私の名刺を見ながら何やら入力。どんな扱いで登録されているのか。尋ねてもはっきりしませんでした。
⬛⬛⬛
会場はソーシャルディスタンス確保（三密対策）のため、予約枠を30分毎に区切り、会場規模に応じて受け入れ人数を制限しています
感染者の中に、会場を訪れた方がいた場合、同日に会場を訪れた全員に電話をかけて自主隔離を依頼します
⬛⬛⬛
●室内には入れてもらえましたが、以下の概要を把握するのは、立ったままでのやり取りとなりました。
▲一日の利用者は約４０人。
▲一人の利用者が申請に至るまでに要する時間は、平均約一時間。
▲９時~１７時の間、職員９人体制。一週間休みなしなのでシフト制を用いている。「では、擁する職員は？」と聞くと「十数人」との答え。「正確には？」ときくと「わからない」との答え。「あなたはここの責任者ですよね」「ええ」とのやり取りも。
▲申請不可に至るケースで多いものは何かを聞いたところ、「売り上げ減が５０%に満たないもの」「給与所得者や雑所得者」との答えでした。
私が「国会答弁で、この両者も対象とされましたよね」と投げかけると「よくわかりません。その話は６月中旬からと言われています」と。「どこから言われたんですか？」に対しては「よくわかりません」。
⬛⬛⬛
で間違いありません
「2020年3月までに創業した事業者や、給与所得者、雑所得者を対象にしたい」
と発言しただけで、閣議決定はされていませんので、まだ対象者ではありません
どこのニュースでも「第2次補正予算案のゆくえ次第」と報道しています
⬛⬛⬛
▲「この会場はいつまでですか？」「わかりません」
⬛⬛⬛
持続化給付金の制度は2021年1月15日までですが、各会場がいつまでかは確定していません
7月末までは決定している会場や、8月末までは決定している会場がいくつか存在しますが、それ以降利用者の少ない会場は閉鎖し、多い会場は継続すると思われます
来場者からの感染者が発覚した場合、その時点で会場は閉鎖になりますので約束は出来ません
⬛⬛⬛
●がらんとした会場は、感染対策とはいえ、どこまで活用されているのかと思いました。４０人の利用者に対して９人というのは、ひとりのスタッフが相対するのは、一日に４．４人。ちなみに、ここでは審査はしていません。つまり申請後の後処理はありません。
業務は直接利用者と相対するだけではないことはよくわかりますが、一つの指標として考えるならば、適正とは言えません。業務には、充分な体制を保障すべきと考える私には、あまり指摘したくない事ですが、運営体制という点では疑問が残ります。
窓口に二人ほど座っています。それ以外に３~４人が会場内にズーッと立っているのは、威圧的な感じさえありました。
⬛⬛⬛
・会場の外で予約を確認し消毒をする係（1〜2人）
・受付で氏名と電話番号を頂戴する係
・記入台付近で記入方法を訊ねられた際に対応する係（1〜2人）
・各種書類をお預かりし、画像データを取り込み、手書き情報をデータ入力する係（最も人数が必要）
・副責任者
申請者様が利用したイス・テーブル・ビニールカーテンは1名ごとにアルコール消毒
休憩を回す事を考えれば順当な人数です
⬛⬛⬛
私が３０分ほどの間に、利用者らしき人は、一瞬の人含め３人でした。
⬛⬛⬛
開場当初は
「予約枠が取れないから直接来た」
と仰る方が続出する状態でした
今でこそ平日は当日予約も可能な程度に余裕が出てきたところです
⬛⬛⬛
●外で待たされている間に許可を得て、外観だけは写真に撮ることができました。
会場内では、写真は禁止されました。人物はもちろん写す気はなく、記載台などを撮りたいといったのですが、無理でした。
「この場を撮ると、どんな差支えがあるのですか」と問うと、「上から言われています」「上ってどこですか？」「事務局です」「どこの事務局ですか？」と聞くと首をかしげていました。
⬛⬛⬛
⬛⬛⬛
●会場から出ても、私は複雑な気持ちでした。「サービスデザイン推進協議会」や電通の問題点とは別に、「あの若者たちの職場としてどうなんだろう」と。
仕事の流れもよくわからず、指揮命令も明確になっていず、会社名を名乗ることもできず、この職場がいつまで存在するのかもわからず…
日本でこのような働き方は少なくないと思います。職業経験が蓄積され、その後の見通しを持てるといった働き方には程遠く、働く人達の立場からも、日本社会としても、危機感を覚えてしまいます。(2020.6.9)
⬛⬛⬛
余計なお世話です
口が酸っぱくなるほど三密を避けろと指示されているのですから、せめて来訪前にアポイントを取ってお越し頂くのが常識です
非正規雇用に甘んじていた結果、有事の際に低賃金労働に就かざるを得ない状況になってしまった事については、己の責任かもしれません
しかし雇用者を開示出来ないのも、天下り団体がのさばっているのも、入札がズブズブなのも、年金が貰えるか分からないのも、税金が上がる一方なのも、アメリカから武器ばかり買っているのも、前世代の人間が政治家の横暴を許し続けた結果です
原文：https://blogs.apache.org/foundation/entry/apache_commons_statement_to_widespread
原題：Apache Commons statement to widespread Java object de-serialisation vulnerability
翻訳日：2015年11月12日（午後にタイトルを日本語にしました）
－－－－
Apache CommonsのJavaオブジェクトのデシリアライゼーション脆弱性に関するステートメント
著者：Bernd Eckenfels（コミッター）, Gary Gregory（Apache Commons副責任者）
AppSecCali2015 でGabriel Lawrence (@gebl) と Chris Frohoff (@frohoff) によって発表された "Marshalling Pickles - how deserializing objects will ruin your day" は、信頼されないソースからシリアル化されたオブジェクトを受け取るときのセキュリティ問題をいくつか明らかにしました。主な発見は、Java オブジェクト・シリアライゼーション（訳注：seriarization／シリアル化／直列化＝ネットワークで送受信できるようにメモリ上のオブジェクトデータをバイト列で吐き出すこと。シリアル化されたJava オブジェクトはRMIなどのリモート通信プロトコルで使用される。）を使用する際に任意のJava関数の実行や操作されたバイトコードの挿入さえもを行う方法の説明です。
Frohoff氏のツールである ysoserial を使って、Foxglove Security社のStephen Breen (@breenmachine) 氏はWebSphereやJBoss、Jenkins、WebLogic、OpenNMSといった様々な製品を調査し、(http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/) に各々の様々な攻撃シナリオを記述しています。
両者の調査活動は、開発者がJavaのオブジェクト・シリアライゼーションに信頼を置きすぎていることを示しています。認証前のシリアル化されていないオブジェクトにも。
Javaにおけるオブジェクトのデシリアライゼーション（訳注：de-serialization／非直列化＝ソフトウェアで扱うことができるように、送受信されたデータを元に戻すこと）が行われるとき、大抵は想定された型にキャストされ、それによって、Javaの厳しい型のシステムが、得られた有効なオブジェクトツリーだけを保証しています。
不幸にも、型のチェックが起こるまでの間に既にプラットホームのコードが生成されて、重要なロジックは実行されてしまっています。そのため、最終的な型がチェックされる前に、開発者のコントロールを離れた多くのコードが様々なオブジェクトの readObject() メソッドを通じて実行されてしまいます。脆弱性のあるアプリケーションのクラスパスから得られるクラスの readObject() メソッドを組み合わせることで、攻撃者は（ローカルのOSのコマンドを実行するRuntime.exec()の呼び出しを含めて）機能を実行することができます。
これに対する最も良い防御は、信頼されていないピア（通信相手）とは複雑なシリアル化プロトコルを使うことを避けることです。ホワイトリストのアプローチ http://www.ibm.com/developerworks/library/se-lookahead/ を実装するように resolveClass をオーバーライドするカスタム版の ObjectInputStream を使うと、影響を制限することができます。しかしながら、これは常にできることではなく、フレームワークやアプリケーションサーバがエンドポイントを提供しているような時にはできません。簡単な修正方法がなく、アプリケーションはクライアント・サーバプロトコルとアーキテクチャを再検討する必要があるため、これはかなり悪いニュースです。
これらのかなり不幸な状況において、エクスプロイトのサンプルが見つかっています。Frohoff氏は、 Groovy ランタイムや Springフレームワーク、 Apache Commons コレクションからのクラスを組み合わせるサンプルのペイロードに gadget chains (ガジェット・チェーン）を見つけています(訳注：provided)。これはこの脆弱性のエクスプロイトのためにより多くのクラスを組み合わせられることは完全に確実なことで、しかし、これらは今日、攻撃者が簡単に得られるチェーンです。
(Twitter画像)https://blogs.apache.org/foundation/mediaresource/ce15e57e-94a4-4d7b-914c-8eb8f026659c
この脆弱性のために利用される(訳注：blamed)ことができない確かな機能を実装するクラスができ、安全性が信用できないコンテキストにおけるシリアル化を利用されないようにするような既知のケースの修正ができたとしても、少なくとも分かったケースだけでも継続的に修正していくことが要求されます。モグラ叩きゲームを始めるだけであるかも知れませんが。実際にはこれは、オリジナルチームが Apache Commons チームに警告が必要だと考えていない理由で、それゆえに比較的、活動開始が遅れました。
Apache Commons チームは InvokerTransformer クラスのでデシリアライゼーションを無効化することによって commons-collection の 3.2 と 4.0 のブランチにおける問題に対処するために、チケット COLLECTION-580(http://svn.apache.org/viewvc/commons/proper/collections/branches/COLLECTIONS_3_2_X/src/java/org/apache/commons/collections/functors/InvokerTransformer.java?r1=1713136&r2=1713307&pathrev=1713307&diff_format=h) を使っています。議論されているやるべきことのアイテムは、変化させる仕組み毎(per-transformer basis)に、プログラマティックに有効にするような機能を提供するかどうかです。
これには前例があります。Oracle と OpenJDK JRE の一部であったり、バイトコードを挿入して実行することを許したりする com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl クラスで、セキュリティマネージャーが定義されているとデシリアライゼーションを拒否します。
これはシステムプロパティ jdk.xml.enableTemplatesImplDeserialization=true とすることで無効にできます。Apache Commons Collection は、本来よりもこの実行モデルは一般化していないため、セキュリティマネージャーの存在と独立したこの機能を無効化することを計画しています。
しかしながら、明確化のために述べておくと、この便利な"ガジェット"は、唯一知られている方法でもなければ、特に未知のものでもありません。そのため、インストールされたものを強化されたバージョンの Apache Commons Collection に置き換えることが、アプリケーションをこの脆弱性に対抗できるようにするわけではありません。
このブログポストのレビューのために Gabriel Lawrence に感謝したいと思います。
Apache Commons Collection は、Java コレクションフレームワークに加えて追加のコレクションクラスを提供する Java ライブラリです。InvokerTransformer はコレクションにあるオブジェクトを（特にリフレクション呼び出しを通じてメソッドを呼び出すことで）変換するために使うことができる Transformer ファンクションインターフェースの実装の一つです。
一般のSallyによる2015年11月10日午前10字15分にポスト | コメント[1]
コメント：
Oracle は Weblogic にセキュリティアラートを発行しています：
