コインチェック株式会社に対する行政処分について：財務省関東財務局
コインチェック株式会社（本店：東京都渋谷区、法人番号1010001148860、資金決済に関する法律（平成21年法律第59号）附則第8条に基づく仮想通貨交換業者）（以下、「当社」という。）においては、平成30年1月26日（金曜）に当社が保有していた仮想通貨（NEM）が不正に外部へ送信され、顧客からの預かり資産5億2,300万XEMが流出するという事故が発生した。 これを踏まえ、同日（26日（金曜））、同法第63条の15第1項の規定に基づく報告を求めたところ、発生原因の究明や顧客への対応、再発防止策等に関し、不十分なことが認められた。 このため、本日、同社に対し、同法第63条の16の規定に基づき、下記の内容の業務改善命令を発出した。
Coincheckで発生した暗号通貨XEMの不正送金事案についてまとめてみた - piyolog
2018年1月26日、コインチェック社が運営する取引所Coincheckにおいて、同社が管理するXEMが外部に送金される事案が発生しました。ここでは関連情報をまとめます。 コインチェック公式発表 プレス 2018年1月27日 Coincheckサービスにおける一部機能の停止について 2018年1月28日 不正に送金された仮想通貨NEMの保有者に対する補償方針について 2018年1月28日 日本円の入金について 2018年1月29日 当社に対する金融庁の業務改善命令について 2018年1月30日 各キャンペーン一時停止のお知らせ 2018年1月30日 出金再開の予定につきまして 2018年1月31日 公式ブログメンテナンスのお知らせ 2018年2月3日 日本円出金の再開の見通しについて 2018年2月9日 日本円出金再開のお知らせ 2018年2月13日 業務改善命令に係る報告書提出のご報告
RDS for MySQL のスロークエリログを可視化して、パフォーマンスをモニタリングする | DevelopersIO
ども、藤本です。 2年前に RDS for MySQL のスロークエリログを Elasticsearch に取り込んで、Kibana で可視化するブログをエントリしました。 RDS for MySQLのスロークエリーログをAWS LambdaでElasticsearchに取り込む ちょいちょい使ってはいたのですが、RDS のログの取り扱いの難しさで完全な取り込みができていない状況でした。先日、RDS for MySQL/MariaDB にてログを CloudWatch Logs へ出力できるようになりました。 RDSのMySQL/MariaDBでログをCloudWatch Logsへ出力可能になりました これを使うことで以前の実装よりも簡単で、かつデータの完全性を高められそうだったのでやってみました。 概要 RDS for MySQL/MariaDB のスロークエリログは簡単に出力、閲覧で
独自解析：コインチェック580億円流出は｢わずか5分｣の犯行と判明、データ解析で探る巨額のゆくえ
仮想通貨取引所コインチェックから、約580億円相当の仮想通貨NEM（ネム）が不正に引き出された問題を受け、Business Insider Japanは、ブロックチェーンに詳しいエンジニアに、コインチェックから仮想通貨が引き出された履歴の解析を依頼した。 その結果、2018年1月26日（時間はいずれも日本時間）、計11回、総額5億2630万10XEM（XEMは、NEMの通貨単位）がNC4で始まるアドレスに送金されていた。また、NC4から9つのアカウントに送金されていることも判明。全体で11アカウントが、不正送金となんらかの関連があるとみられる。 解析に協力してくれたのは主に、ブロックチェーン・ベースの電子政府システムCOMMONS OSの開発を進めているエンジニア河崎純真さん（26）と小副川健さん（36）の2人だ。NEMを含む仮想通貨は、資金の移転がブロックチェーン上の台帳に記録され、ほぼ
コインチェック事件は『対岸の火事』ではない
私は創業してからおよそ２年のベンチャー企業を経営しており、CTO兼唯一のプログラマだ。私含め3人の共同創業者と、多くの支援者の力により、これまで自己資本でなんとか開発を続けてきた。 先日、私達の会社は大きなマイルストンを迎え、サービスをβ公開させ、これから大きく勝負に出ようと思っていた。その最中、今回のコインチェック事件が発生した。 私達が行う事業は暗号通貨とは全く関係が無いため、本来であればこれは『対岸の火事』だ。しかし、総額580億円という被害額を生んだ今回の事件は、暗号通貨市場だけでなく、スタートアップ界隈全体へ影響を及ぼすことが容易に想像される。 事件の余波今回の事件で最も強く感じたのは、技術の力で新領域を切り開くスタートアップ企業こそ、時には成長を犠牲にしてでも、技術的安全性・信頼性を優先するべき、ということだ。 顧客にリスクを押し付けることが絶対に起きてはいけないし、少しでも顧
17行のCコードでMacのシステム全体をフリーズさせられることが出来る不具合がmacOS High Sierraで確認される。
17行のCコードでMacのシステム全体をフリーズさせられることが出来る不具合がmacOS High Sierraで確認されています。詳細は以下から。 先々週、「htopコマンドをmacOS High Sierraで利用すると、システム全体がフリーズしてしまう不具合がる」という記事を書きましたが、その後macOS 10.13.3がリリースされこの不具合が修正されているかを検証していたところ、この不具合がmacOS 10.13.3でも修正されていないことが確認でき、加えてhtopのissueを確認したところ、macOS High Sierraには潜在的な(kernel bug)が存在し、これがhtop実行時にシステム全体をフリーズさせているのではないかというコメントが追加されていたのでチェックしてみました。 Running as non root, yes! The OS is not com
Datadogのアラートtrigger設定項目のon averageの使い方に実は条件があった - まーぽんって誰がつけたの？
on averageはある期間の平均だと思っていた Datadogはこんな風にあるメトリクスの値が閾値を超えたらslackに通知するみたいな感じのことをこうやって設定します 指定したメトリクスの値が、5分間(during the last 5 minutes)の平均(on average)が300を上回ったら(above)アラートするという時の設定です。 なので、この設定で5分間300を超え続けたらアラートになるというつもりで設定してました。 なのに5分間のうちに1回超えただけでアラートになってしまった このタイミングでalertになってしまった。この1本1本が5個連続で300を超えたらアラートになると思ったのに🤔 on averageが使えるのは連続したメトリクスのみでした 公式ドキュメントを読んだらちゃんと書いてありました。 ここで言われている連続したの定義なんだけど、データポイント
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
