2026/02/23 6:07
安全を確保するために、1つだけの回転門（シングルトラベル）を設置いたしました。
RSS: https://news.ycombinator.com/rss
要約▶
Japanese Translation:
入手後、同社は3棟（各棟の高さが最低13階建て）に入り口・エレベーター室、および8階建ての駐車場すべてにキーカードリーダーを設置し、セキュリティ体制を強化しました。各棟1階には通行制御用トランスミッション（ターニング）を追加し、フロアごとに数百人の従業員へのアクセス管理を実施しています。駐車システムは入場前にパスのスキャンが必要で、列ができましたが当初は管理可能でした。
社内JiraツールはAPI呼び出しごとに再認証を行い、トークンを保存せずに処理していましたが、資格情報はベース64エンコードされたクッキーに残っていました。月曜日にはターニングが「モックモード」（ビープ音と緑灯）になりながらも遅延を引き起こしました。火曜日になると完全稼働し、10〜30分の駐車列と混乱したエレベーター交通が発生しました。3日間にわたる運用障害後、ターニングとリーダーはロビーユニット以外すべて無効化されました。
セキュリティ改善策として約1か月後に認証トークン用のRedisサービスを導入しました。配備には詳細なドキュメント作成とベンダー承認が必要で、静かに展開できるようになりました。しかし、Jira資格情報はクッキーに残り続け、対処すべき継続的脆弱性を提示し、相当の提案活動が必要でした。
同社は新デバイスをメールと目立つ設置で祝福し、「セキュリティシアター」を強調しました。従業員はピーク時に駐車場から11階の机へ到達するまで1時間以上の遅延を経験し、Uberライドが一時的な回避策として使用され、駐車場外で混雑が増加しました—これは計画不十分なセキュリティアップグレードが日常業務にどれほど混乱をもたらすかを示しつつ、根本的な脆弱性は残ったままであることを示しています。
本文
企業がより大きな会社に買収された後、セキュリティは最優先事項となりました。
私たちのオフィスは13階以上の高さを誇る3棟から構成されており、各出入口やエレベーター車両、さらには8階建ての駐車場入口にもキーカードリーダーが設置されていました。
まず最初に駐車場システムが稼働しました。車を停めるにはパスカードを読み取る必要があります。すぐに列ができ始めましたが、まだ管理可能な状態でした。
次にドアのセキュリティが有効化されました。私はよくデスクに置き忘れたキーカードで階段で足止めになることがありました。昼食後は11階まで登り、ドアで鍵をかけられてしまうケースも。幸いにもビル内には常に人がおり、誰かがドアを開いてくれるので、私は「自分のカードでは入れない」というメールを見ながら疑わしげに侵入しました。
キーカードへの慣れに苦戦している最中、各棟1階にターニングゲート（トルネット）が設置されました。未来的に見えましたが、デザイナーは考慮していなかった問題を予測していました。各建物は13階で、フロアごとに数百人の従業員がいるため、1人あたりカードスキャンが必要です。
私はソフトウェアエンジニアです。セキュリティはアプリケーション上にオプション機能として追加するものではなく、基盤で保護策を実装するべきだと考えています。実際、私が手掛けていた重要なプロジェクトの一つは、Jiraからタスクを取得する方法を管理するツールでした。以前このブログを読んだことがある方なら、私はいつもJiraについて不満を言っていることをご存知でしょう。
そのアプリケーションのオリジナルデザイナーは時間に追われていたようです。アプリ内の各操作はJiraエンドポイントへの呼び出しを必要とし、そのたびに認証が求められました。彼はAPIから返ってくる認証トークンを保存せず、毎回再認証してタスクを実行する仕組みでした。
ユーザーにパスワードの再入力を求めたのでしょうか？ いいえ。データベースに平文で資格情報を保存したのでしょうか？ いいえ。その代わり、ユーザー名とパスワードをクッキーにBase64エンコードして保存しました。
やがて「全トルネットは有効化される」というメールを受け取りました。翌月曜日にはモックモードで稼働し、カードを読み取ってビープ音と緑灯の表示を待つだけでした。
8:30に到着すると、ロビーでは同僚や数百人の従業員が集まっていました。最初の人物がカードをスキャンすると機械はビープし緑色に点灯しました。我々は拍手で祝福し、順番に機械へ向かいました。ビープ→緑灯→次…しかし、ある従業員ではグラーレッドに変わり、モック日でしたので大丈夫です。私たちはそれぞれの日常を過ごしました。
翌朝、私は車の中で駐車場列に10分以上待っていました。外を見ると各建物周辺に長い列が広がっているのが見えました。
車を停めると、その列は駐車レベルまで続いており、ロビーに到着するまで30分以上かかりました。マネージャーへ遅刻のお知らせをテキストで送ったものの返信はなく、ライン前から手招きされました。
読み取り自体も遅く、承認待ちでした。トルネットを通過するとさらにエレベーター列があり、エレベーターカードリーダーも稼働していました。
数十人の人々が混雑したエレベーターに押し込まれながら、異なるフロアへ向かい、それぞれカードをスキャンしてアクセス権を得ようとする様子は、完全な混乱でした。エレベーターボタンを押す人々が集団でスキャンできず、再度下に戻るケースも多く、フロアごとの混乱が広がりました。
駐車場から11階のデスクへ移動するまでに1時間以上かかりました。
次の日、私はUberを利用して通勤しようとしました。Uberは$3で乗れましたが、同じ考えを持つ百人ほどが並び、駐車場への進入を妨げ、さらなる渋滞を引き起こしました。ビル内でも状況は変わらず、数分しか節約できませんでした。
3日目にトルネットが停止されました。動作しなかったためです。またエレベーターのカードリーダーも無効化されました。これで安心感が得られました。
セキュリティは優先事項とされていましたが、Jiraのクッキーに保存された認証情報については誰も話しませんでした。Redisサービスを導入して生成トークンを保管するよう提案すると、大きな反発がありました。私はドキュメントを書いてベンダーからエンタープライズサポートを求め、1か月でセキュリティ問題を解決しました―盛大なアナウンスはありませんでした。
ロビーに3台の新しいトルネットが設置されたことを祝うメールは届きました。エレベーターのカードリーダーは再び作動しませんでした。これは私たちが経験した混乱の証拠です。
トルネットは目立ち、費用もかさみました。それらは皆の日常を妨げ、会社全体へのメールで話題になりました。経営陣はそれを見て「セキュリティに真剣に取り組んでいる」と語ることができます。一方、数千人の従業員がJira認証情報をクッキーに保存しており、それはプロジェクト管理システム全体を危険にさらす脆弱性です。だがその修正にはドキュメント作成、ベンダー承認、問題重要性の説得という多くの苦労が必要でした。
セキュリティ・シアターはチェックボックスを満たし、人々に何か対策が取られていると感じさせます。実際のセキュリティは目立たず、コードレビューや適切な認証実装、トークン保管など「良いエンジニアリング」が正しく行われている状態です。それにはリボンカット式の儀式も祝賀メールも不要で、誰にも気づかれないほどに完成します。対照的にセキュリティ・シアターは目立つものです。