「note」のIPアドレス表示についての報告とお詫びに見る問題の本質 - novtanの日常
note.jp この件です。 わりとよい報告書みたいな評価をされている人も結構いるんですが、業務エンジニアの目線から見るとこれはちょっと…って言わざるを得ないですね。 再発防止策として書かれているこれね。 1）監視 意図しない漏洩の早期発見・通知を行うシステムの導入 うーんってなりますよね。そもそも、IPアドレスを表示していた（あえて漏洩とは言わない）のは、どういう要件で行っていたのか、という話なわけじゃないですか。表示項目ってのはまずそこからですよね。アプリケーションの作り上、APIとしてやり取りしている項目と、実際に画面に表示している項目は違ったりしますので、業務要件としては表示対象項目しか可視化されてない、ということはよくありますよね。そうすると、APIのI/F定義書を作ったときに画面に表示するための項目とシステム上必要な項目のそれぞれについて、どういった要件に基づくものかを明確にし
ドコモ口座の問題に対するドコモの会見はクソだったけど次は銀行の番じゃないですかね？ - novtanの日常
僕の最近のトレンドは「フロント側の企業を信用するな」ですね。ヤのつく人たちの話ではないですよ（似たようなもんな気がしなくもない）。 今までのシステムが信頼ベースで成り立っていたのは、なんだかんだ言ってその信頼を担保するための手段（あっち側での確認であったり、ちゃんとわかってて偽造したとかじゃない限り手間に見合ったリターンがない印影だったり、そもそも手続きに時間がかかること自体がセキュリティーだったり）があってこそなんですよね。だから、「システムで接続する」場合に責任を取れる自社内でのことであればともかく、相手先のシステムが脆弱であった場合に起きる問題はすべてリスクとして捉えて対応をしなければならない。 だから、Web口振受付の「本人認証」の問題はあまりにも甘すぎる、というのが妥当な評価だと思いますね。事情があってこれしかできない？じゃあやるな（断罪する音）。 もう一度、本人確認 犯罪収益移
Web口振受付と即時口振に頼らなければならない新型決済スキームの問題 - novtanの日常
ドコモ口座の問題はシステム的な部分でいうと「本人確認と認証が甘い」に尽きるんですが、それ以前の問題として、このビジネススキームが何を根拠に成立していて、その根拠に基づいた対応が行われていたか、ということがありますね。なにぶん、それなりに新しいことをやろうとしている話なので必ずしも法整備は十分ではないし、抜け道というか、既存の制度だったらこうすれば使えるよね、というスキームをひねり出して実施していくわけです。なので、根本的な法律や制度の問題とは別に、2者間で成立させるための個別の契約が必ずあるわけです。それがどのくらい今回の事態を想定していたかは定かではないですけれども、少なくともここについて一般に開示されることはないでしょう。でも、そこがキモってのがこの話の難しいところ。 とはいえ、銀行との資金移動に持っていく部分については口振契約ということは明らかですので、そのへんをちょっと考察してみま
IT屋と業務知識について - novtanの日常
年末年始にかけて読んだブログの内容をいまいち飲み込めなかったので噛み砕きも含めて考えてみることにする。 以下、2エントリからの引用であります。 kawaguti.hateblo.jp 私はSIerにいたことがないので、そのあたりどうも疎いのですが、私としては「業務知識といえば、業務実現に必要な知識すべて」のことで、それは担当する業務によって変わってくる、ということではないかな、と思っております。そういう筋で前回のエントリを書きました。 うーむ、となる。業務実現に必要な知識全て、とは一体何か。全てとは。まずここから引っかかる。というのも、僕らIT屋というのはシステムは手段であり、業務とはビジネスそのものである、と思っているからではある。んでもって、業務のうち、ITじゃないシステムの部分をITを使ってよりよくしましょう、というのが僕らの仕事だと思ってるんだよね。だから、「全て」のうちビジネスそ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
