ここが良かった:
「ついでに言うと、こういうものを動かしたことで誰かが怒るなら、どうせそこでは働きたくない可能性が高い。逆に IT やそれに近い組織が『脅威』を感じずにこうしたツールを作れるなら、面白くて役に立つものを作ることを本当に楽しんでいる場所にいるのかもしれない。そういう場所は大切にすべきだ。長く続かないことが多い」
それでもそこで働きたいなら、まず法的状況を確認したほうがいい
ほぼ間違いなく個人情報の無断処理に当たる可能性がある。アクセス権があるからといって、好き勝手にしてよいわけではない。特にアーカイブ、履歴の保存、外部データとの連携は、そうしたインターフェースの意図された利用ではない。情報を業務用ノート PC のような形で自宅に持ち帰ると、また別の問題になり得るし、営業秘密の持ち出しと見なされることもある。
少なくとも欧州では、そうしたインターフェースを悪用することは違法である可能性が高く、コピーや diff を保存していればなおさらだと思う。雇用主は措置を取らなければならない場合があり、取らなければ責任を負う可能性がある。あるいは後になって、この違反を口実に契約を都合よく終了することもできる。特にその情報を交渉材料にするならなおさらだ。
ネットワークが大きいほど、問題に巻き込まれる可能性も高そうだ。逆にそうでなければ、データを集める効用も小さい。むしろ同僚と組織化して雇用情報を自発的に共有し、集団的な交渉力を得るほうがよいのではないか？
無作為なユーザー、さらには匿名ユーザーに会社の全 AD ツリーをインデックスできるようにしている会社を見ると、今でも驚く
親切ではあるが、それでもどうかと思う。また、イントラネットページにはない情報を得る唯一の方法であることも多い。例えば IT に実際どんなチームがあるのか、オフィスがどこにあるのか、誰かのマネージャーが誰なのか、そして当然ながら、社内ポータルへのアクセス問題を引き起こしているどの配布リストに自分が入っておらず、他のユーザーは入っているのか、といったことだ
1件のコメント
Hacker News のコメント
epitaphs を作った者です。何でも聞いてください
従業員が特別なアドレスに内容をメールで送ると、その人が会社を去るときにその内容が表示されることがあります。私はそうしましたが、きちんと動作したかは再確認できません
HR から変更するよう言われたことはありましたか？ 5年前に退職しましたが、あの機能は本当に気に入っていました
こういうものを運用するなら、Git を使うことを強くおすすめします
cron でこんな感じに実行できます:
curl https://internal.corp/employees.txt > employees.txtgit add employees.txtgit commit -m "Automated: $(date -u)" || exit 0|| exit 0は、コミットするものがなくてもエラーにならないようにしてくれます。これで情報源のすべての変更履歴がコミットとして残り、git logを実行するだけで見られます。こういうものをスケジュールされた GitHub Actions で頻繁に回しており、例は https://simonwillison.net/2020/Oct/9/git-scraping/ にあります|| exit 0の代わりにgit commitに--allow-emptyを使っています空コミットができても構いません。自動実行が失敗したのではなく、正常に回ったが変更がなかったと分かるからです
| sortを追加してもよさそうです。こういう 小規模データ には Git は過小評価されているデータベースです高品質で理解しやすい入力を集めるのに大いに役立ちました。ありがとう
https://github.com/hiAndrewQuinn/selkouutiset-scrape/
ただし、こうしたものの上にトランザクションデータベースの機能も欲しいです。Git はこの部分が得意です。同時に一部のフィールドに対する高速なインデックスも欲しいのですが、Git はそこはあまり得意ではありません。そこで、sqlite を Git にダンプする「標準」を試してみようかと考えています。どんなトランザクションでも Git コミットとして表現でき、耐久性と妥当なインデックスのために両方を同時に動かせます。sqlite データベースはいつでも再生成・再インデックスでき、バックアップ用途にもある程度合っています。
まだその場で車輪を空転させている感じで、データベースが次にどこへ向かうのか見守ることになりそうです
こういう形で LDAP を追跡するツールを作りました [0]。LDAP は情報の宝庫で、ストーキングにも非常に向いています
人が去っていくのを見たり、可能ならどれくらい長く働いていたのかを見るのは、なぜか興味深いものでした。友人たちが本人より先に LDAP で解雇された事実を知ることになったのも、かなり興味深かったです。README には、Slack Webhook 連携で LDAP ディレクトリで何が起きているかをオンデマンドに把握し、新入社員・退職者・昇進、HR がいつ何をしているか、不正な変更、誤って流出したデータ、ユーザーの LDAP ログイン・ログアウトを監視できると書きました。Microsoft と Active Directory 向けに実質的に同じことをする LDAPmonitor[1] もあります
[0]https://github.com/MegaManSec/LDAP-Monitoring-Watchdog
[1]https://github.com/p0dalirius/LDAPmonitor
在宅勤務時代のレイオフは奇妙です。以前なら、荷物箱を抱えて出ていく様子を見て、誰が解雇されたのかかなり把握できましたし、近づいて近所のバーで会おうと言ったり、連絡先を交換したりできました。
ある程度の区切りをつけられたのです。今では、ある日から複数の人がメールに返信しなくなり、本当に辞めたのか、ただ忙しいだけなのかが分かるまで待たなければなりません。プロジェクトに必要な成果物を待っている最中なら、それは永遠に届かないかもしれず、しばらく理由も分かりません。社内ディレクトリがあっても、WARN Actのために60日以上残っていることが多く、ほとんどの会社は「解雇者リスト」を作らないようです。誰が解雇されたのかも教えてくれず、解雇の事実を知らせる前にアクセス権を切って別れの挨拶をする機会も与えないなら、区切りをつけるのは本当に難しいです
私が経験した最悪の上司は、退職者の業務引き継ぎデータを探すという名目で、元社員のSlackアカウントへのアクセスを要求していました。彼がその人たちとしてログインするたびに、アカウントが時々緑色になりました。元同僚のアカウントが緑色になるのを見て、上司が個人メッセージを漁っているのだと分かるのは不気味でした。会社がいずれにせよSlackメッセージを見られることは分かっていますが、上司がリアルタイムでそうしているのを見るのは、さらにぞっとします
HRが全員のために数語だけでもまとめようとすること自体が士気をくじく作業で、かつては生き生きとした個人的な手触りがあった場所に、長く残る青白さが生まれました。人々は消え続けますが、去ったという事実や、どのように去ったのかについての告知はいまだにありません。
パンデミック初期にGeneral Counselと最後に会いました。ロックダウン中のほとんどの人と同じく、彼は直系家族以外の誰にも会えず、何か良い話をする機会も何カ月もありませんでした。仮にあったとしても、それが結局彼を死なせていたかもしれません。彼は終わらせようとしていた仕事を一気に話し、その後、弁護士らしくCIOに見事な手紙を書き、私たちの間で最も好きな会話につながりました。
6カ月後、誰かが法務部へ向かっている途中で、誰かが亡くなったと電話してきて、すぐに嫌な予感がしました。Webサイト、ディレクトリ、地域の訃報を探しましたが何もなく、うわさのネットワークも静かでした。そこで彼の秘書に電話したところ、GCは6週間前に亡くなったと、かなり淡々と教えてくれました。
ほぼちょうど1年後になって、ようやく組織の手続きが追いつき、「Remembering $generalCounselor」を出しました。その時にはすでに葬儀を逃しており、家族は引っ越していて、あまりに遅れて弔意を送ることに多くの人が気まずさを感じました。他の人たちの驚き、恥ずかしさ、悲しみを見ることは慰めにはなりませんでしたが、自分だけではなかったのだとは分かりました。
私たちは小さくはないものの個人的なつながりのある組織で、それぞれの死は、共に認めることも扱うこともできなかった小さな空白を残しました。今でも喪失を処理する方法がなく、それについて話してもいません。保存していた古い連絡先が内線の再割り当て後に再び表示されるのは、避けようもなく墓場からの電話のように感じます。連絡を取り続けて追跡しようとしていますが、少しずつつながりは薄れ、彼らと過ごした私たちの記憶と歴史もぼやけていきます
人々がデスクに立ち寄って生活について雑談したり、冗談を言ったりしていたことです。人生であれほど大きく笑ったことはありませんでした。全体としてもっと近い関係で、人が去る時は悲しかったですが、より良い場所へ行くのなら嬉しくもありました。在宅勤務はそれに比べると、あまりに無菌的で非人格的に感じます。2015年ごろから在宅勤務をしてきたので、オフィス復帰を支持しているわけではなく、ただの思い出です
3年間信頼して一緒に働いてきたなら、あと1〜2週間は信頼できます。残った仕事を片付け、時間を取ってもらえばいいのです。私たちはみな大人です。最悪の場合、悪いことが起き得るのは理解していますが、それはいつだって同じです
ここが良かった:
「ついでに言うと、こういうものを動かしたことで誰かが怒るなら、どうせそこでは働きたくない可能性が高い。逆に IT やそれに近い組織が『脅威』を感じずにこうしたツールを作れるなら、面白くて役に立つものを作ることを本当に楽しんでいる場所にいるのかもしれない。そういう場所は大切にすべきだ。長く続かないことが多い」
ほぼ間違いなく個人情報の無断処理に当たる可能性がある。アクセス権があるからといって、好き勝手にしてよいわけではない。特にアーカイブ、履歴の保存、外部データとの連携は、そうしたインターフェースの意図された利用ではない。情報を業務用ノート PC のような形で自宅に持ち帰ると、また別の問題になり得るし、営業秘密の持ち出しと見なされることもある。
少なくとも欧州では、そうしたインターフェースを悪用することは違法である可能性が高く、コピーや diff を保存していればなおさらだと思う。雇用主は措置を取らなければならない場合があり、取らなければ責任を負う可能性がある。あるいは後になって、この違反を口実に契約を都合よく終了することもできる。特にその情報を交渉材料にするならなおさらだ。
ネットワークが大きいほど、問題に巻き込まれる可能性も高そうだ。逆にそうでなければ、データを集める効用も小さい。むしろ同僚と組織化して雇用情報を自発的に共有し、集団的な交渉力を得るほうがよいのではないか？
欧州企業の多くは、従業員がこうしたリストを保管することに慎重になりそうだ
確かめる方法は、同じように構えた HN コメントを探してみることだ。オーバートンの窓が広がった後は、もはや自制せず、こちらが知っていることを堂々と話す。古いアドレス帳を、当事者も驚くようなゴシップ紙に変えるシステムの悪用だ、ということだ。
例えば「最初はどのアカウントが無効化されたかだけを気にしていた。そのうち役職変更、姓の変更（結婚）、部署規模、時間経過に伴う会社の人数などを追跡し始めた」、「LDAP には秘密がぎっしり詰まっている。ほぼすべてを匿名アクセスで得られるなんて。発表前のチーム・部署統合も検出できたし、内部プロジェクトの秘密メーリングリストも、メンバーを見れば何が起きているのか探り出せる」、「多くの奇妙なことは、LDAP ツリーが広くアクセス可能であることに依存している。ただし、たいていの人が思っているより多くの情報が漏れているだけだ」、「人事がいつ何をしているかを監視し、ユーザーが LDAP にログイン・ログアウトするタイミングを検知する」といったものだ
LDAP には秘密がぎっしり詰まっている。会社で何が起きているかを探るには素晴らしい方法で、ほぼすべてを匿名アクセスで取得できる点にも驚かされる
発表前のチームや部署の統合を検出したことがある。内部プロジェクトの秘密メーリングリストも、メンバーを見れば何が起きているのか探り出せる。メールアドレスが一部を明かしていればおまけだ。
ldapsearchは LDAP をよく知っているなら良いし、単に探索したいなら Apache LDAP Studio が優れた UI ツールだ。誰もが、内部アプリ向けに LDAP にバインドするログインサービスを作れる程度には知っておくべきだ。システム管理者が管理するグループを活用してアプリの権限を制御でき、非常に強力で、すぐに始めやすい親切ではあるが、それでもどうかと思う。また、イントラネットページにはない情報を得る唯一の方法であることも多い。例えば IT に実際どんなチームがあるのか、オフィスがどこにあるのか、誰かのマネージャーが誰なのか、そして当然ながら、社内ポータルへのアクセス問題を引き起こしているどの配布リストに自分が入っておらず、他のユーザーは入っているのか、といったことだ
多くの人が同じアイデアに独立してたどり着いていたことに驚く。以前の職場で「the sackinator」を作った
sacked は解雇されたという意味だ。毎晩 AD ディレクトリ全体をダンプする cron ジョブと、任意の 2 日分の出力を diff するスクリプトだった。データがダンプされているので、いつでも戻って追加分析ができた。最初はどのアカウントが無効化されたかだけを見ていたが、後には役職変更、姓の変更（結婚）、部署規模、時間経過に伴う会社の人数などを追跡し始めた。こうしたツールを作ることができ、IT が脅威を感じない場所は大切にすべきだという話には全面的に同意する
ははは。「KTMJ」で管理している非常によく似たスクリプトがある。無効ユーザーを探す目的ではなく、特定の LDAP 属性を別のシステムに同期するためのものだ
この組織は十分に大きく、ユーザー数は 30 万人以上いる。スクリプトが LDAP を照会して同期ファイルを準備し、その後、各ユーザーがまだ存在するかを検証する実際の同期インポートを実行する、その短い間にも、すでに数百のアカウントが無効化されて「error」ログファイルに記録される。実際の同期と「error」ログファイルは、私の直接の管理外にある。
狂ったように笑った理由は、「予算上の制約」により私の契約が終了予定だからだ。すでに何度もレイオフを経験しているので、予想はしていた。私のアカウントも次の月次サイクルで無効化されるアカウントの一つになるはずだが、その前に処理手順と、予想される無効ユーザーの「error」ロギング動作を後任に引き継がなければならない
あまり否定的にばかり見る必要はない。私の職場ではこのツールを「new-hires」と呼んでいる
サードパーティの人事ツールに対する限定的な読み取り専用 API キーを使っており、そのキーは People Director が私にくれたものだ。時々
-で始まる行もあるが、ツール名は+で始まる行から取ったものだ。new-hires は私たちのモノレポにある「people」Python モジュール/CLI の上に作られている。このツールは組織図の diff よりはるかに有用だ。誰がどのチームにいるのか、どこにいるのか、今日勤務しているのか、勤続記念日を祝うタイミングなのか、といったことが分かる。また、良い CLI ツールのために私が作った「ZFS リトマス試験」にも従っており、パース可能でヘッダーなしの出力のために
-pHを提供している。こういう場所は本当に大切にする価値がある最初の職場でこういうシステムを作ろうとしたが、マネージャーがそれを聞いて明示的に禁止した
後にその会社は 1 日でソフトウェアエンジニアの 15% を解雇した。サポートチームが公開の課題トラッカーに従業員アカウント廃止のチケットを作成したため、多くの人が会議の連絡を受ける前に、その方法で先に知ることになった